perm filename W89[JNK,JMC] blob
sn#871511 filedate 1989-03-22 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00935 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00140 00002 ∂12-Dec-88 1528 X3J13-mailer Issue: TAILP-NIL (Version 5)
C00152 00003 ∂12-Dec-88 1601 X3J13-mailer Re: Issue: TEST-NOT-IF-NOT (Version 3)
C00153 00004 ∂12-Dec-88 1609 X3J13-mailer Issue: TYPE-OF-UNDERCONSTRAINED (Version 3)
C00163 00005 ∂12-Dec-88 1622 X3J13-mailer Issue: REST-LIST-ALLOCATION (Version 3)
C00177 00006 ∂12-Dec-88 1623 X3J13-mailer Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 2)
C00183 00007 ∂12-Dec-88 1643 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Call for Papers Workshop on Automatic Verification Methods for
C00189 00008 ∂12-Dec-88 1648 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Crypto '89 -- Call for Papers
C00198 00009 ∂12-Dec-88 1735 X3J13-mailer CommonLisp/C interface
C00200 00010 ∂12-Dec-88 1755 X3J13-mailer Issue: TAILP-NIL (Version 5)
C00202 00011 ∂12-Dec-88 1838 X3J13-mailer ** BALLOT ** BALLOT ** BALLOT ** BALLOT **
C00217 00012 ∂13-Dec-88 0800 X3J13-mailer CommonLisp/C interface
C00219 00013 ∂13-Dec-88 0819 X3J13-mailer CommonLisp/C interface
C00224 00014 ∂13-Dec-88 0833 X3J13-mailer Re: CommonLisp/C interface
C00226 00015 ∂13-Dec-88 0910 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Call for Papers
C00234 00016 ∂13-Dec-88 1115 X3J13-mailer [barmar@Think.COM: CommonLisp/C interface]
C00238 00017 ∂13-Dec-88 1120 X3J13-mailer CommonLisp/C interface
C00243 00018 ∂13-Dec-88 1233 X3J13-mailer Re: CommonLisp/C interface
C00247 00019 ∂13-Dec-88 1442 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu cs300
C00249 00020 ∂13-Dec-88 1649 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Calgary theory positions
C00256 00021 ∂13-Dec-88 1719 betsy@russell.Stanford.EDU Schedule for 1988-89
C00258 00022 ∂14-Dec-88 1043 X3J13-mailer Re: [barmar@Think.COM: CommonLisp/C interface]
C00261 00023 ∂14-Dec-88 1157 X3J13-mailer Issue: PACKAGE-CLUTTER (Version 6)
C00263 00024 ∂14-Dec-88 1205 X3J13-mailer Re: [barmar@Think.COM: CommonLisp/C interface]
C00265 00025 ∂14-Dec-88 1659 X3J13-mailer Hawaii registration
C00269 00026 ∂14-Dec-88 1707 X3J13-mailer Re: CommonLisp/C interface
C00274 00027 ∂15-Dec-88 0802 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Call for Papers/Distributed Comp Workshop South of France
C00282 00028 ∂15-Dec-88 0929 X3J13-mailer Re: [barmar@Think.COM: CommonLisp/C interface]
C00285 00029 ∂15-Dec-88 0945 X3J13-mailer Re: [barmar@Think.COM: CommonLisp/C interface]
C00287 00030 ∂15-Dec-88 1424 @Score.Stanford.EDU:jps@amadeus.Stanford.EDU panel on federal science funding
C00293 00031 ∂15-Dec-88 1504 X3J13-mailer Hawaii registration form
C00297 00032 ∂15-Dec-88 1525 X3J13-mailer Hawaii registration form OOOPS!
C00299 00033 ∂15-Dec-88 1715 X3J13-mailer Symbolics Cambridge office is moving
C00301 00034 ∂15-Dec-88 1716 @Score.Stanford.EDU:jwilson@jaguar.Stanford.EDU [SLOAN@Score.Stanford.EDU: Theft]
C00303 00035 ∂16-Dec-88 0847 X3J13-mailer Re: [barmar@Think.COM: CommonLisp/C interface]
C00305 00036 ∂16-Dec-88 1306 @Score.Stanford.EDU:mkatz@sesame.stanford.edu [SLOAN@Score.Stanford.EDU: Theft]
C00308 00037 ∂16-Dec-88 1313 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Undecidability of containment
C00311 00038 ∂16-Dec-88 1315 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: TCS geneology
C00313 00039 ∂16-Dec-88 1319 JONES@Score.Stanford.EDU Winter quarter AI classes
C00321 00040 ∂16-Dec-88 1352 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Call for papers FOCS 89
C00329 00041 ∂16-Dec-88 1448 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Distr.Comp.Workshop France, Corrected Version
C00337 00042 ∂16-Dec-88 1547 HEMENWAY@Score.Stanford.EDU more proposals
C00343 00043 ∂16-Dec-88 1613 @Score.Stanford.EDU:jcm@ra.stanford.edu PhD proposal
C00346 00044 ∂16-Dec-88 1656 @Score.Stanford.EDU:baskett@SGI.COM [SLOAN@Score.Stanford.EDU: Theft]
C00349 00045 ∂16-Dec-88 1821 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu #P-complete problem
C00352 00046 ∂16-Dec-88 1837 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu AMAST -- Second Call for Abstracts
C00360 00047 ∂17-Dec-88 1546 @Score.Stanford.EDU:RWF@SAIL.Stanford.EDU re: more proposals
C00363 00048 ∂18-Dec-88 0030 @polya.Stanford.EDU:pehoushe@Gang-of-Four.Stanford.EDU Re: #P-complete problem, the 12x12 case.
C00366 00049 ∂18-Dec-88 1603 LOGMTC-mailer beeson
C00367 00050 ∂19-Dec-88 0922 STAGER@Score.Stanford.EDU Another Winter Quarter AI Class of Interest
C00369 00051 ∂19-Dec-88 0924 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: #P-complete problem, the 12x12 case.
C00373 00052 ∂19-Dec-88 0930 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Bar-Ilan Symposium Announcement
C00381 00053 ∂19-Dec-88 0940 @Score.Stanford.EDU:jlh@vsop.Stanford.EDU Re: more proposals
C00384 00054 ∂19-Dec-88 0952 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Capital City Conference
C00399 00055 ∂19-Dec-88 1030 DEWERK@Score.Stanford.EDU CS-TAC Shutdown.
C00401 00056 ∂19-Dec-88 1114 @polya.Stanford.EDU:mendel@ois.db.toronto.edu Positions in Toronto
C00403 00057 ∂19-Dec-88 1426 @Score.Stanford.EDU:dill@amadeus.Stanford.EDU Re: more proposals
C00414 00058 ∂19-Dec-88 1519 @Score.Stanford.EDU:dill@amadeus.Stanford.EDU PhD research discussion
C00416 00059 ∂19-Dec-88 1621 @Score.Stanford.EDU:wheaton@athena.stanford.edu visitor
C00418 00060 ∂19-Dec-88 1637 @Score.Stanford.EDU:HALPERN@IBM.COM Re: research
C00423 00061 ∂19-Dec-88 2207 @Score.Stanford.EDU:jcm@ra.stanford.edu research
C00428 00062 ∂19-Dec-88 2233 @Score.Stanford.EDU:cheriton@Pescadero.Stanford.EDU Re: research
C00430 00063 ∂19-Dec-88 2242 X3J13-mailer Corrections to the ISO Report
C00437 00064 ∂19-Dec-88 2338 @Score.Stanford.EDU:eaf@sumex-aim.stanford.edu Re: more proposals
C00439 00065 ∂20-Dec-88 0233 X3J13-mailer Gabriel's report
C00444 00066 ∂20-Dec-88 0757 X3J13-mailer Re: Gabriel's report
C00447 00067 ∂20-Dec-88 1137 X3J13-mailer access to the standard
C00449 00068 ∂20-Dec-88 1301 @Score.Stanford.EDU:tah@linz PhD Requirements & Research
C00451 00069 ∂20-Dec-88 1544 @Score.Stanford.EDU:goldberg@polya.Stanford.EDU Ph.D. research
C00454 00070 ∂20-Dec-88 1816 @polya.Stanford.EDU:tah@linz Minimal models
C00457 00071 ∂20-Dec-88 2226 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Complete axiom sets for arithmetic equations,
C00463 00072 ∂20-Dec-88 2301 @Score.Stanford.EDU:linton@interviews.stanford.edu Re: Ph.D. research
C00465 00073 ∂21-Dec-88 0910 @Score.Stanford.EDU:daniel@mojave.Stanford.EDU Ph.D. research: the difference between exam requirements and course requirements.
C00469 00074 ∂21-Dec-88 0913 aaai@sumex-aim.stanford.edu Happy Holidays!
C00470 00075 ∂21-Dec-88 0946 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU comprehensives and research orientation
C00473 00076 ∂21-Dec-88 0946 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: Linear Programming Program Needed
C00476 00077 ∂21-Dec-88 1013 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: Complete axiom sets for arithmetic equations
C00481 00078 ∂21-Dec-88 1328 SLOAN@Score.Stanford.EDU Closing of offices tomorrow
C00483 00079 ∂21-Dec-88 1347 @Score.Stanford.EDU:pratt@chehalis.stanford.edu status of "cs.stanford.edu"
C00485 00080 ∂21-Dec-88 1351 @Score.Stanford.EDU:RWF@SAIL.Stanford.EDU re: Ph.D. research: the difference between exam requirements and course requirements.
C00488 00081 ∂21-Dec-88 1605 @Score.Stanford.EDU:pratt@chehalis Re: Ph.D. research: the difference between exam requirements and course requirements.
C00491 00082 ∂21-Dec-88 1722 @Score.Stanford.EDU:RWF@SAIL.Stanford.EDU re: Ph.D. research: the difference between exam requirements and course requirements.
C00493 00083 ∂21-Dec-88 1930 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Complete axiom sets for arithmetic equations,
C00498 00084 ∂21-Dec-88 1935 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Complete axiom sets for arithmetic equations
C00501 00085 ∂22-Dec-88 0925 @Score.Stanford.EDU:RPG@SAIL.Stanford.EDU Students and Research
C00509 00086 ∂22-Dec-88 1028 @Score.Stanford.EDU:gio@sumex-aim.stanford.edu Re: comprehensives and research orientation
C00511 00087 ∂22-Dec-88 1049 @Score.Stanford.EDU:winograd@loire.stanford.edu Re: research
C00514 00088 ∂22-Dec-88 1139 X3J13-mailer Error terminology
C00516 00089 ∂22-Dec-88 1147 TAJNAI@Score.Stanford.EDU Sunrise Club, Jan. 17.
C00518 00090 ∂22-Dec-88 1241 X3J13-mailer Re: Corrections to the ISO Report
C00527 00091 ∂22-Dec-88 1356 @Score.Stanford.EDU:eaf@sumex-aim.stanford.edu Re: comprehensives and research orientation
C00529 00092 ∂22-Dec-88 1447 X3J13-mailer Re: Corrections to the ISO Report
C00538 00093 ∂22-Dec-88 1545 ruben@apple.com Re: Philosophy Colloquium Dec. 9
C00540 00094 ∂22-Dec-88 1709 @Score.Stanford.EDU:RWF@SAIL.Stanford.EDU The Way We Were
C00543 00095 ∂23-Dec-88 0811 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Complete axiom sets for arithmetic equations
C00546 00096 ∂23-Dec-88 0823 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Center for Discrete Mathematics and Theoretical Computer Science
C00552 00097 ∂23-Dec-88 0825 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Announcement: DIMACS and Special Year.
C00559 00098 ∂23-Dec-88 1747 @Score.Stanford.EDU:eaf@sumex-aim.stanford.edu Re: The Way We Were
C00564 00099 ∂25-Dec-88 1351 @polya.Stanford.EDU:coraki!pratt@Sun.COM Minimal models
C00571 00100 ∂26-Dec-88 1541 @Score.Stanford.EDU:daniel@mojave.Stanford.EDU Ph.D. research: the difference between exam requirements and course requirements.
C00575 00101 ∂27-Dec-88 1134 @Score.Stanford.EDU:jlh@vsop.Stanford.EDU Re: Ph.D. research: the difference between exam requirements and course requirements.
C00579 00102 ∂27-Dec-88 1445 LOGMTC-mailer Model theoretic properties of universal horn sentences
C00581 00103 ∂27-Dec-88 1659 @Score.Stanford.EDU:binford@Boa-Constrictor.Stanford.EDU comps
C00586 00104 ∂28-Dec-88 1229 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu The *Other* Unification Algorithm, I
C00603 00105 ∂28-Dec-88 1337 aaai@sumex-aim.stanford.edu NTU
C00615 00106 ∂28-Dec-88 1531 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu amended "call for papers" for AMAST Conference
C00624 00107 ∂28-Dec-88 2238 @Score.Stanford.EDU:eaf@sumex-aim.stanford.edu Re: comps
C00628 00108 ∂29-Dec-88 0523 LOGMTC-mailer Re: Model theoretic properties of universal horn sentences
C00631 00109 ∂31-Dec-88 1755 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Happy New Year!
C00649 00110 ∂03-Jan-89 0832 @Score.Stanford.EDU:chandler@polya.Stanford.EDU First Faculty Lunch....Winter Quarter
C00651 00111 ∂03-Jan-89 1027 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Recursion Theorems, a question on litterature.
C00655 00112 ∂03-Jan-89 1031 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Second Call for Papers
C00667 00113 ∂03-Jan-89 1038 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Call for Papers
C00673 00114 ∂03-Jan-89 1228 X3J13-mailer Hawaii registration status
C00679 00115 ∂03-Jan-89 1324 X3J13-mailer issues from cl-compiler
C00681 00116 ∂03-Jan-89 1358 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu DARPA Announcement
C00690 00117 ∂03-Jan-89 1406 @Score.Stanford.EDU:bhayes@polya.Stanford.EDU Re: DARPA Announcement
C00692 00118 ∂03-Jan-89 1424 X3J13-mailer issue ALLOW-LOCAL-INLINE
C00701 00119 ∂03-Jan-89 1426 X3J13-mailer issue COMPILE-ENVIRONMENT-CONSISTENCY
C00715 00120 ∂03-Jan-89 1428 X3J13-mailer issue DEFCONSTANT-SPECIAL
C00722 00121 ∂03-Jan-89 1429 X3J13-mailer issue LOAD-TIME-EVAL
C00738 00122 ∂03-Jan-89 1432 X3J13-mailer issue SHARP-COMMA-CONFUSION
C00746 00123 ∂03-Jan-89 1604 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu cs300
C00749 00124 ∂03-Jan-89 1618 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Visit to SUN Microsystems
C00751 00125 ∂03-Jan-89 1631 @Score.Stanford.EDU:chandler@polya.Stanford.EDU 1/10 Faculty Meeting
C00753 00126 ∂03-Jan-89 1719 LOGMTC-mailer Talk Thurs
C00756 00127 ∂04-Jan-89 0931 @Score.Stanford.EDU:tom@polya.Stanford.EDU heating problem
C00758 00128 ∂04-Jan-89 1043 LOGMTC-mailer Seminar in Logic
C00761 00129 ∂04-Jan-89 1049 @Score.Stanford.EDU:gio@sumex-aim.stanford.edu Re: DARPA Announcement
C00763 00130 ∂04-Jan-89 1109 @Score.Stanford.EDU:tom@polya.Stanford.EDU DARPA Announcement
C00765 00131 ∂04-Jan-89 1115 @Score.Stanford.EDU:tom@polya.Stanford.EDU DARPA Announcement
C00767 00132 ∂04-Jan-89 1412 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Theory Net
C00770 00133 ∂04-Jan-89 1428 @Score.Stanford.EDU:cheriton@Pescadero.Stanford.EDU Re: DARPA Announcement
C00772 00134 ∂04-Jan-89 1739 @Score.Stanford.EDU:gio@sumex-aim.stanford.edu Re: DARPA Announcement
C00775 00135 ∂04-Jan-89 2028 @Score.Stanford.EDU:DEK@SAIL.Stanford.EDU First Faculty Lunch --- Winter Quarter
C00777 00136 ∂05-Jan-89 1055 debra@russell REMINDER
C00778 00137 ∂05-Jan-89 1342 X3J13-mailer ISO discussion and X3J13 Agenda DRAFT
C00782 00138 ∂05-Jan-89 1616 lansky@ai.sri.com SRI AIRR Seminar: TUESDAY, JANUARY 10, 2pm -- John Josephson
C00786 00139 ∂06-Jan-89 0843 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Urgent: Update to PODC Call for Papers
C00794 00140 ∂06-Jan-89 0917 aaai@sumex-aim.stanford.edu Council Conference Call
C00796 00141 ∂06-Jan-89 0921 @Score.Stanford.EDU:tom@polya.Stanford.EDU Dover retirement
C00799 00142 ∂06-Jan-89 1023 @Score.Stanford.EDU:chandler@polya.Stanford.EDU 1-10-89 Faculty Meeting
C00802 00143 ∂06-Jan-89 1203 @Score.Stanford.EDU:winograd@loire.stanford.edu SEMINAR ON COMPUTERS, ETHICS, and SOCIAL RESPONSIBILITY
C00807 00144 ∂06-Jan-89 1216 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Urgent: Semantics of Programming Languages
C00812 00145 ∂06-Jan-89 1239 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu URGENT: Noerteastern University Theory Day
C00816 00146 ∂06-Jan-89 1304 ULLMAN@Score.Stanford.EDU help save some fish
C00818 00147 ∂06-Jan-89 1442 ARCEO@Warbucks.AI.SRI.COM SEMINAR - JANUARY 11th (Wednesday)
C00822 00148 ∂06-Jan-89 1504 X3J13-mailer Ballots, please
C00824 00149 ∂06-Jan-89 2136 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Urgent: SPAA Deadline Approaching. Call for papers follows:
C00831 00150 ∂06-Jan-89 2239 @Score.Stanford.EDU:cheriton@Pescadero.Stanford.EDU Re: Dover retirement
C00833 00151 ∂06-Jan-89 2253 X3J13-mailer Issue: DECLARE-TYPE-FREE (Version 9)
C00854 00152 ∂07-Jan-89 0933 X3J13-mailer Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS, version 8
C00873 00153 ∂07-Jan-89 0935 X3J13-mailer Issue CONSTANT-MODIFICATION, version 2
C00878 00154 ∂07-Jan-89 0944 X3J13-mailer **DRAFT** Issue COMPILER-DIAGNOSTICS, version 8
C00905 00155 ∂07-Jan-89 0946 X3J13-mailer **DRAFT** Issue COMPILER-VERBOSITY, version 5
C00917 00156 ∂07-Jan-89 1048 X3J13-mailer issues relating to compiled constants
C00920 00157 ∂07-Jan-89 1048 X3J13-mailer **DRAFT** issue CONSTANT-COMPILABLE-TYPES
C00948 00158 ∂07-Jan-89 1049 X3J13-mailer **DRAFT** issue CONSTANT-CIRCULAR-COMPILATION
C00959 00159 ∂07-Jan-89 1050 X3J13-mailer **DRAFT** issue CONSTANT-COLLAPSING
C00965 00160 ∂07-Jan-89 1050 X3J13-mailer **DRAFT** issue QUOTE-MAY-COPY
C00991 00161 ∂07-Jan-89 1311 X3J13-mailer **DRAFT** issue EVAL-WHEN-NON-TOP-LEVEL, version 4
C01002 00162 ∂07-Jan-89 1316 X3J13-mailer **DRAFT** issue DEFINING-MACROS-NON-TOP-LEVEL, version 7
C01013 00163 ∂08-Jan-89 2342 CL-Compiler-mailer **DRAFT** issue CONSTANT-COMPILABLE-TYPES
C01015 00164 ∂09-Jan-89 0848 X3J13-mailer Editorial committee issues
C01017 00165 ∂09-Jan-89 0849 X3J13-mailer Issue:DEPRECATION-POSITION
C01025 00166 ∂09-Jan-89 0851 X3J13-mailer Issue:CUT-OFF-DATES
C01034 00167 ∂09-Jan-89 0851 X3J13-mailer Issue:SUBSETTING-POSITION
C01042 00168 ∂09-Jan-89 0852 X3J13-mailer Issue:CONFORMANCE-POSITION
C01048 00169 ∂09-Jan-89 0933 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu URGENT: Northeastern University Theory Day - Corrections
C01052 00170 ∂09-Jan-89 0939 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Urgent: Semantics of Programming Languages
C01057 00171 ∂09-Jan-89 0943 LOGMTC-mailer Seminar reminders
C01059 00172 ∂09-Jan-89 1132 @Score.Stanford.EDU:chandler@polya.Stanford.EDU General Faculty Meeting
C01061 00173 ∂09-Jan-89 1149 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Tomorrow's Faculty Lunch
C01063 00174 ∂09-Jan-89 1155 X3J13-mailer Issue:EXTENSIONS-POSITION
C01071 00175 ∂09-Jan-89 1242 X3J13-mailer Re: Issue:SUBSETTING-POSITION
C01075 00176 ∂09-Jan-89 1257 lansky@ai.sri.com AIRR Seminar Reminder
C01079 00177 ∂09-Jan-89 1303 X3J13-mailer revised ISO discussion, revised DRAFT Gegenda and Subcommittee meetings
C01083 00178 ∂09-Jan-89 1607 @polya.Stanford.EDU:dill@amadeus.Stanford.EDU Harry Lewis Talk
C01087 00179 ∂09-Jan-89 1632 @polya.Stanford.EDU:tah@linz MTC Seminar
C01089 00180 ∂09-Jan-89 1705 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Urgent: Invited Lecture
C01094 00181 ∂09-Jan-89 1712 @polya.Stanford.EDU:ARCEO@Warbucks.AI.SRI.COM SEMINAR - JANUARY 11th (Wednesday)
C01098 00182 ∂09-Jan-89 2246 misha@polya.Stanford.EDU Next AFLB
C01101 00183 ∂10-Jan-89 0817 TAJNAI@Score.Stanford.EDU Reminder of Sunrise Club breakfast on Tuesday, 1/17
C01103 00184 ∂10-Jan-89 0905 X3J13-mailer FTP access to compiler issues
C01105 00185 ∂10-Jan-89 0935 X3J13-mailer **DRAFT** issue COMPILED-FUNCTION-REQUIREMENTS, version 2
C01116 00186 ∂10-Jan-89 1011 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu [jadams@note.nsf.gov: CISE Newsletter]
C01142 00187 ∂10-Jan-89 1104 SLOAN@Score.Stanford.EDU Fax Machine
C01144 00188 ∂10-Jan-89 1214 debra@russell.Stanford.EDU REMINDER
C01146 00189 ∂10-Jan-89 1238 X3J13-mailer summary of open cl-compiler issues
C01154 00190 ∂10-Jan-89 1307 barwise@russell.Stanford.EDU Interns
C01159 00191 ∂10-Jan-89 1350 @Score.Stanford.EDU:ungar@self Re: Reminder of Sunrise Club breakfast on Tuesday, 1/17
C01161 00192 ∂10-Jan-89 1543 X3J13-mailer Issue: APPLYHOOK-ENVIRONMENT (Version 2)
C01166 00193 ∂10-Jan-89 1555 X3J13-mailer Issue: COMPLEX-ATAN-BRANCH-CUT, (Version 1)
C01171 00194 ∂10-Jan-89 1710 X3J13-mailer Issue: DEFSTRUCT-ACCESS-FUNCTIONS-INLINE, (Version 2)
C01175 00195 ∂10-Jan-89 1836 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu [jadams@note.nsf.gov: CISE Newsletter]
C01201 00196 ∂10-Jan-89 2258 @Score.Stanford.EDU:cheriton@Pescadero.Stanford.EDU Re: [jadams@note.nsf.gov: CISE Newsletter]
C01204 00197 ∂10-Jan-89 2349 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Urgent: announcement of panel on funding
C01210 00198 ∂11-Jan-89 1429 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu
C01215 00199 ∂11-Jan-89 1433 X3J13-mailer Another DRAFT Agenda
C01219 00200 ∂11-Jan-89 1435 @Score.Stanford.EDU:jle@Orange.stanford.edu CS Colloquium
C01221 00201 ∂11-Jan-89 1441 @polya.Stanford.EDU:phipps@solitary.Stanford.EDU new meeting time
C01223 00202 ∂11-Jan-89 1441 lansky@ai.sri.com Of possible interest....
C01229 00203 ∂11-Jan-89 1510 byrd@sumex-aim.stanford.edu Cm* book
C01231 00204 ∂11-Jan-89 1516 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: Urgent: announcement of panel on funding
C01233 00205 ∂11-Jan-89 1605 eaf@sumex-aim.stanford.edu Re: Cm* book
C01235 00206 ∂11-Jan-89 1649 X3J13-mailer Issue: IEEE-ATAN-BRANCH-CUT (Version 2)
C01243 00207 ∂11-Jan-89 1703 X3J13-mailer Issue: LISP-PACKAGE-NAME, (Version 1)
C01258 00208 ∂11-Jan-89 1731 hoffman@csli.Stanford.EDU the Symbolic Systems Forum Schedule Winter 89
C01260 00209 ∂11-Jan-89 1815 emma@csli.Stanford.EDU CSLI Calendar, January 12, 4:11
C01270 00210 ∂11-Jan-89 2008 X3J13-mailer Ballot (finally)
C01292 00211 ∂11-Jan-89 2233 X3J13-mailer Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 6)
C01301 00212 ∂11-Jan-89 2237 X3J13-mailer Issue: SPECIAL-TYPE-SHADOWING (Version 1)
C01307 00213 ∂11-Jan-89 2316 X3J13-mailer Issue: THE-AMBIGUITY (Version 2)
C01315 00214 ∂11-Jan-89 2346 X3J13-mailer Issue: UNDEFINED-VARIABLES-AND-FUNCTIONS (Version 1)
C01326 00215 ∂11-Jan-89 2357 X3J13-mailer Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE (Version 3)
C01334 00216 ∂12-Jan-89 0015 X3J13-mailer Issue: EQUAL-STRUCTURE, (Version 6)
C01345 00217 ∂12-Jan-89 0104 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 4)
C01358 00218 ∂12-Jan-89 0117 X3J13-mailer Issue: APPEND-ATOM (Version 1)
C01366 00219 ∂12-Jan-89 0121 X3J13-mailer Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
C01377 00220 ∂12-Jan-89 1004 @Score.Stanford.EDU:laudon@Portia.stanford.edu Jan 17 federal funding panel
C01382 00221 ∂12-Jan-89 1413 X3J13-mailer Issue: CLOSE-CONSTRUCTED-STREAM (Version 2)
C01391 00222 ∂12-Jan-89 1445 @Score.Stanford.EDU:weening@Gang-of-Four.Stanford.EDU USENET newsgroups for classes
C01393 00223 ∂12-Jan-89 1526 X3J13-mailer Issue: REMF-MULTIPLE (Version 2)
C01401 00224 ∂12-Jan-89 1642 X3J13-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
C01428 00225 ∂12-Jan-89 1647 @Score.Stanford.EDU:eyal@coyote.stanford.edu Broadcast of courses on SUNet
C01432 00226 ∂12-Jan-89 1711 X3J13-mailer Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)
C01444 00227 ∂12-Jan-89 1731 X3J13-mailer Issue: PACKAGE-FUNCTION-CONSISTENCY (Version 2)
C01452 00228 ∂12-Jan-89 1836 @Score.Stanford.EDU:allison@shasta.stanford.edu Re: Broadcast of courses on SUNet
C01455 00229 ∂12-Jan-89 1928 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU re: Broadcast of courses on SUNet
C01457 00230 ∂12-Jan-89 2125 @Score.Stanford.EDU:dill@amadeus.Stanford.EDU re: Broadcast of courses on SUNet
C01459 00231 ∂12-Jan-89 2245 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: Broadcast of courses on SUNet
C01461 00232 ∂13-Jan-89 0102 @Score.Stanford.EDU:eaf@sumex-aim.stanford.edu Re: Broadcast of courses on SUNet
C01463 00233 ∂13-Jan-89 0833 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Tuesday's Facutly Lunch
C01465 00234 ∂13-Jan-89 0851 @Score.Stanford.EDU:RPG@SAIL.Stanford.EDU Broadcast of courses on SUNet
C01467 00235 ∂13-Jan-89 0900 @Score.Stanford.EDU:cleron@polya.Stanford.EDU Re: Broadcast of courses on SUNet
C01470 00236 ∂13-Jan-89 0909 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: Broadcast of courses on SUNet
C01473 00237 ∂13-Jan-89 0918 TAJNAI@Score.Stanford.EDU Broadcast of courses on SUNet
C01476 00238 ∂13-Jan-89 0928 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Tuesday's Faculty Lunch
C01478 00239 ∂13-Jan-89 1013 @Score.Stanford.EDU:tom@polya.Stanford.EDU SITN
C01481 00240 ∂13-Jan-89 1029 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: SITN
C01483 00241 ∂13-Jan-89 1043 @Score.Stanford.EDU:bhayes@polya.Stanford.EDU faculty mailing list
C01485 00242 ∂13-Jan-89 1143 @Score.Stanford.EDU:eyal@coyote.stanford.edu Re: broadcast of courses on SUNet
C01490 00243 ∂13-Jan-89 1609 @Score.Stanford.EDU:ungar@self Re: SITN
C01492 00244 ∂13-Jan-89 1629 @Score.Stanford.EDU:bhayes@polya.Stanford.EDU SITN metadiscussion
C01496 00245 ∂13-Jan-89 2326 @Score.Stanford.EDU:cheriton@Pescadero.Stanford.EDU More on broadcast of courses
C01501 00246 ∂13-Jan-89 2328 barwise@russell.Stanford.EDU Interns
C01503 00247 ∂14-Jan-89 0006 @Score.Stanford.EDU:allison@shasta.stanford.edu More on the TV question
C01505 00248 ∂14-Jan-89 0037 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU re: More on the TV question
C01508 00249 ∂14-Jan-89 0803 @Score.Stanford.EDU:CAB@SAIL.Stanford.EDU Professional TV lectures
C01510 00250 ∂14-Jan-89 0935 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu mailing lists
C01512 00251 ∂14-Jan-89 0939 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu space in mjh
C01514 00252 ∂14-Jan-89 1147 @Score.Stanford.EDU:dill@amadeus.Stanford.EDU TV
C01518 00253 ∂14-Jan-89 2005 @Score.Stanford.EDU:ungar@self Re: TV
C01520 00254 ∂15-Jan-89 1203 TAJNAI@Score.Stanford.EDU [Tracy Larrabee <larrabee@polya.Stanford.EDU>: Re: COMPUTER FORUM ---POSTER SESSION -- REVISED DEADLINE ]
C01526 00255 ∂15-Jan-89 1321 @Score.Stanford.EDU:coraki!pratt@Sun.COM Occasional summaries of student opinion
C01528 00256 ∂15-Jan-89 1326 @Score.Stanford.EDU:coraki!pratt@Sun.COM Re: SITN
C01530 00257 ∂15-Jan-89 1336 @Score.Stanford.EDU:gio@sumex-aim.stanford.edu TV and lectures, my vote
C01532 00258 ∂16-Jan-89 1103 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu CSD Retreat
C01535 00259 ∂16-Jan-89 1107 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Tuesday Lunch
C01537 00260 ∂16-Jan-89 1235 @Score.Stanford.EDU:hayes@arisia.xerox.com SITN
C01539 00261 ∂16-Jan-89 1245 @Score.Stanford.EDU:hayes@arisia.xerox.com More on the TV question
C01542 00262 ∂16-Jan-89 1255 @Score.Stanford.EDU:hayes@arisia.xerox.com Professional TV lectures
C01545 00263 ∂16-Jan-89 1314 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Text in programming language semantics
C01548 00264 ∂16-Jan-89 1333 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu [moran@Warbucks.AI.SRI.COM: RFC: Ethics of the Internet]
C01556 00265 ∂16-Jan-89 1402 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Faculty positions at University of Haifa
C01559 00266 ∂16-Jan-89 1403 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Towards an Online Rolodex
C01563 00267 ∂16-Jan-89 1406 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Finite Halting Problem Considered Solvable
C01570 00268 ∂16-Jan-89 1406 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Theory positon at Michigan
C01576 00269 ∂16-Jan-89 1407 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu an improved Boolean matrix multiplication algorithm
C01583 00270 ∂16-Jan-89 1502 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Registration information for EUROCRYPT '89
C01596 00271 ∂16-Jan-89 1503 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Solving BITMAP Rotation in place
C01608 00272 ∂16-Jan-89 1602 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu ASL logic meeting at UCLA
C01622 00273 ∂16-Jan-89 1606 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Call for Participation
C01640 00274 ∂17-Jan-89 0933 @Score.Stanford.EDU:goldberg@polya.Stanford.EDU Re: More on the TV question
C01642 00275 ∂17-Jan-89 1129 @Score.Stanford.EDU:bhayes@polya.Stanford.EDU Re: Occasional summaries of student opinion
C01646 00276 ∂17-Jan-89 1444 misha@polya.Stanford.EDU Next AFLB
C01649 00277 ∂17-Jan-89 1605 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu yet another bibliography request: logic programming
C01652 00278 ∂17-Jan-89 1629 @polya.Stanford.EDU:DEK@SAIL.Stanford.EDU Wednesday not Friday
C01654 00279 ∂17-Jan-89 1748 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu dismay
C01657 00280 ∂17-Jan-89 1840 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: Urgent: announcement of panel on funding
C01660 00281 ∂18-Jan-89 0049 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Prosser & Winkel : A joke or what....???
C01663 00282 ∂18-Jan-89 0054 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: SITN
C01668 00283 ∂18-Jan-89 0100 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: broadcasting classes
C01673 00284 ∂18-Jan-89 0102 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: SITN
C01677 00285 ∂18-Jan-89 0106 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: SITN
C01680 00286 ∂18-Jan-89 0108 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU The best lectures I ever attended
C01684 00287 ∂18-Jan-89 0111 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Televised Classes
C01690 00288 ∂18-Jan-89 0720 @polya.Stanford.EDU:Ekaterini.Yannoulis@pulsar.fac.cs.cmu.edu Undeliverable mail
C01696 00289 ∂18-Jan-89 1035 @Score.Stanford.EDU:coraki!pratt@Sun.COM TV
C01698 00290 ∂18-Jan-89 1114 aaai@sumex-aim.stanford.edu CMU Email Interface
C01704 00291 ∂18-Jan-89 1116 @Score.Stanford.EDU:jwilson@jaguar.Stanford.EDU NeXT machine installed near MJH 246
C01706 00292 ∂18-Jan-89 1216 misha@polya.Stanford.EDU Correction on TODAY'S talk by bernd Sturmfels
C01707 00293 ∂18-Jan-89 1227 LOGMTC-mailer seminar on lambda calculus and PL semantics
C01709 00294 ∂18-Jan-89 1236 aaai@sumex-aim.stanford.edu trucated message
C01710 00295 ∂18-Jan-89 1252 LOGMTC-mailer seminar on lambda calculus and PL semantics
C01711 00296 ∂18-Jan-89 1323 aaai@sumex-aim.stanford.edu resending CMU interface info
C01734 00297 ∂18-Jan-89 1457 @polya.Stanford.EDU:imielins@aramis.rutgers.edu PODS 89 - Final Program
C01755 00298 ∂18-Jan-89 1537 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu SIGACT News Deadline
C01758 00299 ∂18-Jan-89 1823 emma@csli.Stanford.EDU CSLI Calendar, January 19, 4:12
C01765 00300 ∂18-Jan-89 1842 @polya.Stanford.EDU:tah@linz MTC Seminar
C01767 00301 ∂19-Jan-89 0820 tcr@sumex-aim.stanford.edu IBM ARC CS Seminar
C01772 00302 ∂19-Jan-89 0835 HEMENWAY@Score.Stanford.EDU Need Someone for Orals Committee
C01774 00303 ∂19-Jan-89 0908 HEMENWAY@Score.Stanford.EDU Let the Games Begin!
C01777 00304 ∂19-Jan-89 1035 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu SIGACT News Deadline
C01780 00305 ∂19-Jan-89 1049 @Score.Stanford.EDU:chandler@polya.Stanford.EDU The case of the missing fedora.....
C01782 00306 ∂19-Jan-89 1126 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Last Call for Papers
C01797 00307 ∂19-Jan-89 2324 hoffman@csli.Stanford.EDU Symbolic Systems Forum Reminder
C01799 00308 ∂20-Jan-89 0852 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Faculty Lunch
C01801 00309 ∂20-Jan-89 1049 @Score.Stanford.EDU:chandler@polya.Stanford.EDU CSD Retreat
C01803 00310 ∂20-Jan-89 1230 LOGMTC-mailer seminar in logic
C01805 00311 ∂20-Jan-89 1532 @Score.Stanford.EDU:latombe@coyote.stanford.edu Re: CSD Retreat
C01807 00312 ∂20-Jan-89 1630 @polya.Stanford.EDU:decwrl!decvax!gatech!cs.utexas.edu!utep-vaxa!teodor@labrea.stanford.edu mailing list
C01810 00313 ∂21-Jan-89 0042 hoffman@csli.Stanford.EDU Symbolic Systems Forum Jan 27th
C01813 00314 ∂21-Jan-89 1406 byrd@sumex-aim.stanford.edu object-oriented paper
C01815 00315 ∂23-Jan-89 1016 @Score.Stanford.EDU:winograd@loire.stanford.edu PhD program discussion
C01819 00316 ∂23-Jan-89 1048 debra@russell.Stanford.EDU REMINDER
C01821 00317 ∂23-Jan-89 1051 X3J13-mailer Issues DECLARATION-SCOPE and DEFINING-MACROS-NON-TOP-LEVEL
C01824 00318 ∂23-Jan-89 1059 debra@russell.Stanford.EDU EVENING SEMINAR REMINDER
C01825 00319 ∂23-Jan-89 1409 X3J13-mailer Second edition of "Common Lisp: The Language"
C01833 00320 ∂23-Jan-89 1423 X3J13-mailer cl-compiler issues
C01836 00321 ∂23-Jan-89 1459 @Score.Stanford.EDU:jle@Orange.stanford.edu CS Colloquia
C01841 00322 ∂23-Jan-89 1503 misha@polya.Stanford.EDU TWO AFLB talks this week!
C01845 00323 ∂23-Jan-89 1518 saraiya@sumex-aim.stanford.edu [Nevena Raykovic <nevena@pescadero.stanford.edu> : CS548-Distributed
C01848 00324 ∂23-Jan-89 1722 TAJNAI@Score.Stanford.EDU "taxes on gifts"
C01856 00325 ∂24-Jan-89 0852 @Score.Stanford.EDU:gio@sumex-aim.stanford.edu Re: "taxes on gifts"
C01858 00326 ∂24-Jan-89 0905 TAJNAI@Score.Stanford.EDU Re: "taxes on gifts"
C01860 00327 ∂24-Jan-89 0942 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu POSITION ANNOUNCEMENT
C01864 00328 ∂24-Jan-89 0944 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Theory Day - last announcement
C01868 00329 ∂24-Jan-89 1133 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu STOC '89: TENTATIVE PROGRAM
C01879 00330 ∂24-Jan-89 1231 CL-Characters-mailer Comments on the Character proposal dated January 1, 1989
C01904 00331 ∂24-Jan-89 1312 CL-Characters-mailer Comments on the Character proposal dated January 1, 1989
C01907 00332 ∂24-Jan-89 1325 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Sorting on NxN Mesh.
C01915 00333 ∂24-Jan-89 1736 misha@polya.Stanford.EDU This week's AFLB
C01918 00334 ∂24-Jan-89 1949 @Score.Stanford.EDU,@polya.Stanford.EDU:hayes@arisia.xerox.com teaching strategies
C01925 00335 ∂25-Jan-89 0613 X3J13-mailer Issues DECLARATION-SCOPE and DEFINING-MACROS-NON-TOP-LEVEL
C01931 00336 ∂25-Jan-89 0850 X3J13-mailer Issues DECLARATION-SCOPE and DEFINING-MACROS-NON-TOP-LEVEL
C01933 00337 ∂25-Jan-89 0936 X3J13-mailer Issues DECLARATION-SCOPE and DEFINING-MACROS-NON-TOP-LEVEL
C01936 00338 ∂25-Jan-89 1320 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Forsythe Lectures/Ruzena Bajcsy
C01938 00339 ∂25-Jan-89 1555 snoeyink@polya.Stanford.EDU Next BATS
C01939 00340 ∂25-Jan-89 1732 emma@csli.Stanford.EDU CSLI Calendar, January 26, 4:13
C01948 00341 ∂26-Jan-89 0002 X3J13-mailer Re: Comments on the Character proposal dated January 1, 1989
C01956 00342 ∂26-Jan-89 0920 TAJNAI@Score.Stanford.EDU book signing at the Forum annual meeting
C01958 00343 ∂26-Jan-89 0924 @Score.Stanford.EDU:goldberg@Jinn.stanford.edu Industrial Lecturer Appointment
C01960 00344 ∂26-Jan-89 1349 GENESERETH@Score.Stanford.EDU Re: Industrial Lecturer Appointment
C01962 00345 ∂26-Jan-89 1352 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Combinatorial Enumeration Question
C01965 00346 ∂26-Jan-89 1403 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu TCS day at Maryland
C01970 00347 ∂26-Jan-89 1444 TAJNAI@Score.Stanford.EDU Affiliates "Tax"
C01984 00348 ∂26-Jan-89 1803 X3J13-mailer Re: Comments on the Character proposal dated January 1, 1989
C01989 00349 ∂26-Jan-89 1926 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu SUMMER MEETING FOR YOUNG SCIENTISTS
C01996 00350 ∂26-Jan-89 1928 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu bibliography on semantics of inheritance
C02004 00351 ∂26-Jan-89 2139 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu PODS 89 - advanced program
C02025 00352 ∂26-Jan-89 2300 @polya.Stanford.EDU:tah@linz MTC Seminar
C02027 00353 ∂27-Jan-89 0307 X3J13-mailer Issues DECLARATION-SCOPE and DEFINING-MACROS-NON-TOP-LEVEL
C02030 00354 ∂27-Jan-89 0825 @Score.Stanford.EDU:chandler@polya.Stanford.EDU 1/31 Faculty Lunch
C02032 00355 ∂27-Jan-89 0833 @Score.Stanford.EDU:tom@polya.Stanford.EDU NCUBE
C02035 00356 ∂27-Jan-89 0918 @Score.Stanford.EDU:tom@polya.Stanford.EDU alto's/dovers
C02037 00357 ∂27-Jan-89 1041 @Score.Stanford.EDU:goldberg@Jinn.stanford.edu Potential visitor
C02039 00358 ∂27-Jan-89 1101 @Score.Stanford.EDU:goldberg@Jinn.stanford.edu Industrial Lecturer
C02041 00359 ∂27-Jan-89 1329 @Score.Stanford.EDU,@polya.Stanford.EDU:hayes@arisia.xerox.com NCUBE
C02044 00360 ∂29-Jan-89 1101 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu CIS Mentor program
C02046 00361 ∂29-Jan-89 1251 hoffman@csli.Stanford.EDU The Symbolic Systems Forum Feb. 3rd
C02049 00362 ∂29-Jan-89 1433 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU Protesting the censorship of a newsgroup
C02051 00363 ∂29-Jan-89 1436 @Score.Stanford.EDU:Mailer@SAIL.Stanford.EDU rec.humor.funny
C02054 00364 ∂29-Jan-89 1449 @Score.Stanford.EDU:Mailer@SAIL.Stanford.EDU Censoring rec.humor.funny
C02065 00365 ∂29-Jan-89 1508 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU rec.humor.funny
C02069 00366 ∂29-Jan-89 1721 @Score.Stanford.EDU:coraki!pratt@Sun.COM rec.humor.funny
C02072 00367 ∂29-Jan-89 1804 LOGMTC-mailer Logic seminar
C02075 00368 ∂30-Jan-89 0743 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Faculty Lunch: The PhD Program
C02088 00369 ∂30-Jan-89 0747 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Spokespersons meeting of Jan. 23, 1989
C02092 00370 ∂30-Jan-89 0750 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Teaching Strategies
C02097 00371 ∂30-Jan-89 0753 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Comps and PhD program
C02102 00372 ∂30-Jan-89 0756 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: A Comp Retrospective
C02106 00373 ∂30-Jan-89 0759 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: Comps and PhD program
C02110 00374 ∂30-Jan-89 0802 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: Comps and PhD program
C02113 00375 ∂30-Jan-89 0805 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Apprenticeship
C02118 00376 ∂30-Jan-89 0808 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: Comps and PhD program
C02122 00377 ∂30-Jan-89 0811 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: Comps and PhD program
C02126 00378 ∂30-Jan-89 0814 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: Apprenticeship
C02129 00379 ∂30-Jan-89 0817 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU re: Comps and PhD program
C02133 00380 ∂30-Jan-89 0820 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU re: Comps and PhD program
C02136 00381 ∂30-Jan-89 0822 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Comprehensive Exams
C02140 00382 ∂30-Jan-89 0826 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Sr Staff Meeting
C02145 00383 ∂30-Jan-89 0830 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU A Comp Retrospective
C02152 00384 ∂30-Jan-89 0833 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: A Comp Retrospective
C02155 00385 ∂30-Jan-89 0837 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: A Comp Retrospective
C02158 00386 ∂30-Jan-89 0842 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: More-on the Faculty Lunch
C02163 00387 ∂30-Jan-89 0850 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Forwarding Mail
C02166 00388 ∂30-Jan-89 0857 @Score.Stanford.EDU:hayes@arisia.xerox.com rec.humor.funny
C02169 00389 ∂30-Jan-89 1118 @Score.Stanford.EDU:tom@polya.Stanford.EDU Large automated NFS file/archive server
C02172 00390 ∂30-Jan-89 1124 @Score.Stanford.EDU:Mailer@SAIL.Stanford.EDU misquote
C02174 00391 ∂30-Jan-89 1142 @Score.Stanford.EDU,@polya.Stanford.EDU:TAJNAI@Score.Stanford.EDU Re: Large automated NFS file/archive server
C02176 00392 ∂30-Jan-89 1225 @Score.Stanford.EDU:katiyar@polya.Stanford.EDU winter potluck (volunteer wanted)
C02179 00393 ∂30-Jan-89 1336 LOGMTC-mailer Carl Gunter talk 2/8
C02183 00394 ∂31-Jan-89 0132 X3J13-mailer Comments on the Character proposal dated January 1, 1989
C02192 00395 ∂31-Jan-89 0942 STAGER@Score.Stanford.EDU Autumn Quarter Tau Beta Pi
C02193 00396 ∂31-Jan-89 1357 CL-Characters-mailer Comments on the Character proposal dated January 1, 1989
C02198 00397 ∂31-Jan-89 1405 misha@polya.Stanford.EDU This week's AFLB
C02202 00398 ∂31-Jan-89 1528 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu sorting on nxn mesh
C02206 00399 ∂31-Jan-89 2321 @Score.Stanford.EDU:ag@pepper.stanford.edu acquiring a multiprocessor
C02209 00400 ∂01-Feb-89 0910 HEMENWAY@Score.Stanford.EDU Meeting Reminder
C02211 00401 ∂01-Feb-89 1353 X3J13-mailer Fairfax information and registration form
C02217 00402 ∂01-Feb-89 1759 emma@csli.Stanford.EDU CSLI Calendar, February 2, 4:14
C02224 00403 ∂01-Feb-89 2146 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Thirteenth Columbia University Theory Day
C02228 00404 ∂02-Feb-89 0859 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Minutes to 1/10 Faculty Meeting
C02230 00405 ∂02-Feb-89 0927 TAJNAI@Score.Stanford.EDU program for the Forum Conference
C02232 00406 ∂02-Feb-89 1102 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu What Exit Seminar Series
C02235 00407 ∂02-Feb-89 1121 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Conference on Math. Foundations of Prog. Semantics
C02248 00408 ∂02-Feb-89 1307 X3J13-mailer Really about TYPEP failures: Comments on the Character proposal dated January 1, 1989
C02258 00409 ∂02-Feb-89 1613 @polya.Stanford.EDU:tah@linz MTC Seminar
C02261 00410 ∂02-Feb-89 1639 STAGER@Score.Stanford.EDU Preliminary Class Lists
C02262 00411 ∂02-Feb-89 1644 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Found: one cute lemma, doesn't answer to any name.
C02265 00412 ∂02-Feb-89 1729 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu NIPS CALL FOR PAPERS
C02272 00413 ∂02-Feb-89 1815 snoeyink@polya.Stanford.EDU Bats Speakers and Abstracts
C02284 00414 ∂02-Feb-89 1826 snoeyink@polya.Stanford.EDU Going to BATS
C02288 00415 ∂02-Feb-89 2125 hoffman@csli.Stanford.EDU This Friday's (the 3rd) Symbolic Systems Forum
C02291 00416 ∂02-Feb-89 2345 LOGMTC-mailer Seminar in Logic
C02294 00417 ∂03-Feb-89 0824 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Next Tuesday's Faculty Lunch
C02296 00418 ∂03-Feb-89 0840 HEMENWAY@Score.Stanford.EDU Round 1
C02299 00419 ∂03-Feb-89 0907 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu [jadams@note.nsf.gov: Educational Supplements to CISE-Research Grants]
C02305 00420 ∂03-Feb-89 1130 HEMENWAY@Score.Stanford.EDU GRE Analytical Scores
C02307 00421 ∂03-Feb-89 2333 X3J13-mailer Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES (Version 3)
C02314 00422 ∂05-Feb-89 1020 X3J13-mailer Fairfax and Hotel badness
C02316 00423 ∂05-Feb-89 1104 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu [fuller@sierra.STANFORD.EDU: Grants of HP equipment]
C02320 00424 ∂05-Feb-89 2223 hoffman@csli.Stanford.EDU The Symbolic Systems Forum, Feb. 10th
C02324 00425 ∂06-Feb-89 0008 misha@polya.Stanford.EDU Next AFLB
C02326 00426 ∂06-Feb-89 0921 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Tomorrow's Faculty Lunch
C02328 00427 ∂06-Feb-89 1854 snoeyink@polya.Stanford.EDU Bats Speakers and Abstracts
C02340 00428 ∂06-Feb-89 1926 LOGMTC-mailer Seminar cancellation
C02341 00429 ∂06-Feb-89 2000 misha@polya.Stanford.EDU Next AFLB
C02343 00430 ∂07-Feb-89 1041 debra@russell.Stanford.EDU REMINDER-Evening Seminar
C02345 00431 ∂07-Feb-89 1329 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Interval splitting problem
C02348 00432 ∂07-Feb-89 1355 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu A WORKSHOP ON CELLULAR AUTOMATA
C02352 00433 ∂07-Feb-89 1405 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Feasible Mathematics Workshop -- Announcement
C02357 00434 ∂07-Feb-89 1428 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: Sorting on NxN Mesh.
C02364 00435 ∂07-Feb-89 1455 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu collision in DES: distributed and probabilistic algorithm
C02371 00436 ∂07-Feb-89 1505 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu CALL FOR PAPERS -Conference BCTCS5
C02381 00437 ∂07-Feb-89 1543 X3J13-mailer What-a-Guy!
C02386 00438 ∂07-Feb-89 1735 LOGMTC-mailer Carl Gunter Reminder
C02390 00439 ∂08-Feb-89 0736 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Program Extraction / Calculus of Constructions
C02393 00440 ∂08-Feb-89 0752 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu
C02398 00441 ∂08-Feb-89 0828 HEMENWAY@Score.Stanford.EDU Round 1 Meeting
C02400 00442 ∂08-Feb-89 1107 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Ruzena Bacjsy
C02402 00443 ∂08-Feb-89 1607 @polya.Stanford.EDU:tah@linz MTC Seminar
C02404 00444 ∂08-Feb-89 1622 misha@polya.Stanford.EDU AFLB TOMORROW!!
C02407 00445 ∂08-Feb-89 1651 TAJNAI@Score.Stanford.EDU need FORUM RSVP
C02409 00446 ∂09-Feb-89 0436 X3J13-mailer Preview of things to come from editorial committee
C02413 00447 ∂09-Feb-89 0437 X3J13-mailer Issue: CUT-OFF-DATES
C02433 00448 ∂09-Feb-89 0440 X3J13-mailer Issue: FONTS
C02437 00449 ∂09-Feb-89 0444 X3J13-mailer Issue: TOC
C02447 00450 ∂09-Feb-89 0537 X3J13-mailer Issue: ERROR-TERMINOLOGY
C02465 00451 ∂09-Feb-89 0831 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Hong Kong International Computer Conference
C02468 00452 ∂09-Feb-89 0928 X3J13-mailer Re: Issue: ERROR-TERMINOLOGY
C02471 00453 ∂09-Feb-89 0959 X3J13-mailer Re: Issue: ERROR-TERMINOLOGY
C02477 00454 ∂09-Feb-89 1003 emma@csli.Stanford.EDU CSLI Calendar, 9 February, 4:15
C02485 00455 ∂09-Feb-89 1008 X3J13-mailer Issue: ERROR-TERMINOLOGY
C02490 00456 ∂09-Feb-89 1059 X3J13-mailer Re: Issue: ERROR-TERMINOLOGY
C02493 00457 ∂09-Feb-89 1059 snoeyink@polya.Stanford.EDU [irani@ernie.Berkeley.EDU: BATS Correction]
C02496 00458 ∂09-Feb-89 1248 lansky@ai.sri.com AI-RR Seminar -- TUESDAY (Valentine's Day) -- 2pm -- W.Zadrozny
C02500 00459 ∂10-Feb-89 0819 HEMENWAY@Score.Stanford.EDU Batch 3 folders
C02502 00460 ∂10-Feb-89 1018 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Disk Space problems on Polya
C02505 00461 ∂10-Feb-89 1031 STAGER@Score.Stanford.EDU 1989/90 Courses and Degrees
C02507 00462 ∂10-Feb-89 1038 @Score.Stanford.EDU:farhad@polya.Stanford.EDU Re: Disk Space problems on Polya
C02512 00463 ∂10-Feb-89 1041 @Score.Stanford.EDU:ball@polya.Stanford.EDU Disk Space problems on Polya
C02514 00464 ∂10-Feb-89 1055 LOGMTC-mailer Seminar in Logic
C02517 00465 ∂10-Feb-89 1449 HEMENWAY@Score.Stanford.EDU Round 1 Meeting
C02519 00466 ∂11-Feb-89 1339 @polya.Stanford.EDU:tah@linz Faculty candidate
C02521 00467 ∂12-Feb-89 1619 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Calendar Advisory
C02524 00468 ∂13-Feb-89 0023 barwise@russell.Stanford.EDU Question from student
C02528 00469 ∂13-Feb-89 0750 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Tomorrow's Faculty Lunch
C02530 00470 ∂13-Feb-89 1018 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Forsythe Lectures
C02533 00471 ∂13-Feb-89 1141 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu faculty meeting
C02536 00472 ∂13-Feb-89 1332 barwise@russell.Stanford.EDU SS GRad students
C02543 00473 ∂13-Feb-89 1404 lansky@ai.sri.com AI-RR SEMINAR REMINDER -- TUESDAY AT 2PM
C02547 00474 ∂13-Feb-89 2001 misha@polya.Stanford.EDU AFLB tomorrow at 11 am!
C02549 00475 ∂13-Feb-89 2222 @Score.Stanford.EDU:jle@Orange.stanford.edu CS Colloquium/Forsythe Lecture
C02554 00476 ∂14-Feb-89 0309 hoffman@csli.Stanford.EDU The Symbolic Systems Forum, Feb. 17th
C02557 00477 ∂14-Feb-89 0904 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Faculty Lunch
C02559 00478 ∂14-Feb-89 0922 X3J13-mailer X3J13/ISO overlap
C02561 00479 ∂14-Feb-89 1012 aaai@sumex-aim.stanford.edu Next Council Meeting
C02563 00480 ∂14-Feb-89 1226 X3J13-mailer Copying and Equality paper
C02565 00481 ∂14-Feb-89 1235 SLOAN@Score.Stanford.EDU
C02567 00482 ∂14-Feb-89 1240 @Score.Stanford.EDU:jle@Orange.stanford.edu Milk & Cookies
C02569 00483 ∂14-Feb-89 1318 snoeyink@polya.Stanford.EDU Bats Speakers and Abstracts
C02581 00484 ∂14-Feb-89 2115 LOGMTC-mailer "Categories for working logicians"
C02585 00485 ∂15-Feb-89 0953 @Score.Stanford.EDU:chandler@polya.Stanford.EDU CSD Retreat
C02588 00486 ∂15-Feb-89 1200 LOGMTC-mailer Thurs seminar
C02589 00487 ∂15-Feb-89 1209 @Score.Stanford.EDU:tom@polya.Stanford.EDU Epoch Systems server/archive
C02591 00488 ∂15-Feb-89 1451 TAJNAI@Score.Stanford.EDU Computer Forum Reception
C02593 00489 ∂15-Feb-89 1541 barwise@russell.Stanford.EDU courses for next year
C02595 00490 ∂15-Feb-89 1656 HEMENWAY@Score.Stanford.EDU The Last Batch
C02597 00491 ∂16-Feb-89 0427 barwise@russell.Stanford.EDU grad courses and seminars
C02600 00492 ∂16-Feb-89 0431 barwise@russell.Stanford.EDU Re: grad courses and seminars
C02602 00493 ∂16-Feb-89 0859 GOTELLI@Score.Stanford.EDU New Rates for Polya
C02605 00494 ∂16-Feb-89 0905 hyde@csli.Stanford.EDU csli calendar, Feb. 16, 4:16
C02615 00495 ∂16-Feb-89 1302 @Score.Stanford.EDU:katiyar@polya.Stanford.EDU WINTER POTLUCK
C02621 00496 ∂16-Feb-89 1657 @Score.Stanford.EDU:goldberg@Jinn.stanford.edu Needed: Industrial Lecturers
C02623 00497 ∂16-Feb-89 1808 tah@polya.Stanford.EDU MTC Seminar
C02624 00498 ∂17-Feb-89 0003 @Score.Stanford.EDU:marty@cis.Stanford.EDU WINTER POTLUCK
C02626 00499 ∂17-Feb-89 0014 @Score.Stanford.EDU:marty@cis.Stanford.EDU Needed: Industrial Lecturers
C02628 00500 ∂17-Feb-89 0019 @Score.Stanford.EDU:marty@cis.Stanford.EDU CSD Retreat
C02630 00501 ∂17-Feb-89 0842 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu $50K
C02632 00502 ∂17-Feb-89 0909 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Next Tuesday's Faculty Lunch
C02634 00503 ∂17-Feb-89 0931 LOGMTC-mailer Logic Seminar
C02636 00504 ∂17-Feb-89 1139 @Score.Stanford.EDU:RWF@SAIL.Stanford.EDU Comprehensive Structure Long-term Committees
C02643 00505 ∂17-Feb-89 1202 @Score.Stanford.EDU:goldberg@Jinn.stanford.edu Industrial Lecturers
C02645 00506 ∂18-Feb-89 1439 @Score.Stanford.EDU:gio@sumex-aim.stanford.edu Re: Comprehensive Structure Long-term Committees
C02648 00507 ∂18-Feb-89 2234 @Score.Stanford.EDU:jcm@ra.stanford.edu Re: Comprehensive Structure Long-term Committees
C02650 00508 ∂19-Feb-89 1446 LOGMTC-mailer The Symbolic Systems Forum, Feb. 24th
C02653 00509 ∂20-Feb-89 0129 X3J13-mailer Issue: SUBSETTING-POSITION
C02663 00510 ∂20-Feb-89 1255 X3J13-mailer Re: Issue: SUBSETTING-POSITION
C02667 00511 ∂20-Feb-89 1406 X3J13-mailer Issue: CONFORMANCE-POSITION
C02674 00512 ∂20-Feb-89 1452 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu SIGACT Newletter
C02678 00513 ∂20-Feb-89 1747 misha@polya.Stanford.EDU Next AFLB
C02682 00514 ∂21-Feb-89 0638 X3J13-mailer Updated version of standard available
C02691 00515 ∂21-Feb-89 0755 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU Proposed CSD statement on censorship of rec.humor.funny
C02696 00516 ∂21-Feb-89 0800 @Score.Stanford.EDU:chandler@polya.Stanford.EDU At today's faculty lunch......
C02698 00517 ∂21-Feb-89 0858 BSCOTT@Score.Stanford.EDU [AS.BTH@Forsythe.Stanford.EDU: Army RFP]
C02706 00518 ∂21-Feb-89 1002 HEMENWAY@Score.Stanford.EDU Round 2 Schedule
C02713 00519 ∂21-Feb-89 1021 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu staff and lunch
C02716 00520 ∂21-Feb-89 1053 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Today's Faculty Meeting
C02718 00521 ∂21-Feb-89 1101 @Score.Stanford.EDU:chandler@polya.Stanford.EDU ["Joyce R. Chandler" <chandler@polya.stanford.edu> : Today's Faculty
C02721 00522 ∂21-Feb-89 1108 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Today's Faculty Meeting
C02723 00523 ∂21-Feb-89 1118 debra@russell.Stanford.EDU REMINDER-Evening Seminar
C02725 00524 ∂21-Feb-89 1143 acuff@sumex-aim.stanford.edu New disk on file server
C02728 00525 ∂21-Feb-89 1310 lansky@ai.sri.com AI-RR Seminar THIS THURSDAY -- 3:15pm -- Jay Weber
C02732 00526 ∂21-Feb-89 1552 @Score.Stanford.EDU:hayes@arisia.xerox.com Proposed CSD statement on censorship of rec.humor.funny
C02734 00527 ∂21-Feb-89 1610 @Score.Stanford.EDU:goldberg@polya.Stanford.EDU Ph.D. program
C02739 00528 ∂21-Feb-89 1633 @Score.Stanford.EDU:ungar@self Re: Ph.D. program
C02740 00529 ∂21-Feb-89 1734 @Score.Stanford.EDU:jcm@ra.stanford.edu Ph.D. program
C02742 00530 ∂21-Feb-89 1937 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU draft extra sentence to precede final paragraph
C02743 00531 ∂21-Feb-89 2149 X3J13-mailer Source for section 2.4
C02764 00532 ∂21-Feb-89 2150 X3J13-mailer Source for section 6.1
C02785 00533 ∂21-Feb-89 2151 X3J13-mailer Feb. 21 Letter Ballot
C02792 00534 ∂21-Feb-89 2153 X3J13-mailer Issue: TOC
C02803 00535 ∂21-Feb-89 2155 X3J13-mailer Issue: FONTS
C02807 00536 ∂21-Feb-89 2201 X3J13-mailer Issue: CUT-OFF-DATES
C02827 00537 ∂21-Feb-89 2201 X3J13-mailer Issue: ERROR-TERMINOLOGY
C02849 00538 ∂21-Feb-89 2149 X3J13-mailer Source for section 1.8
C02852 00539 ∂21-Feb-89 2208 X3J13-mailer Source for section 2.5
C02915 00540 ∂21-Feb-89 2209 X3J13-mailer Source for section 2.3
C02978 00541 ∂21-Feb-89 2210 @Score.Stanford.EDU:linton@interviews.Stanford.EDU Re: Ph.D. program
C02982 00542 ∂21-Feb-89 2237 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu NIPS POST-MEETING WORKSHOPS
C02989 00543 ∂21-Feb-89 2239 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu WADS '89
C02995 00544 ∂21-Feb-89 2241 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Seventh Amsterdam Colloquium -- Call for papers
C03001 00545 ∂21-Feb-89 2243 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Call for papers - FST&TCS9
C03008 00546 ∂21-Feb-89 2250 @Score.Stanford.EDU:gio@sumex-aim.stanford.edu Re: Ph.D. program
C03010 00547 ∂21-Feb-89 2251 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Structure in Complexity Theory - Preliminary Program
C03020 00548 ∂22-Feb-89 0023 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu CO89 Combinatorial Optimization Conference
C03031 00549 ∂22-Feb-89 0030 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Capital City Conference on Combinatorics and Theoretical Computer
C03046 00550 ∂22-Feb-89 0052 @Score.Stanford.EDU:cheriton@Pescadero.Stanford.EDU Re: draft extra sentence to precede final paragraph
C03049 00551 ∂22-Feb-89 0121 @Score.Stanford.EDU:cheriton@Pescadero.Stanford.EDU Random theories of PhD-ology
C03053 00552 ∂22-Feb-89 1059 @Score.Stanford.EDU:hayes@arisia.xerox.com draft extra sentence to precede final paragraph
C03057 00553 ∂22-Feb-89 1110 @Score.Stanford.EDU:bhayes@polya.Stanford.EDU Proposed changes
C03060 00554 ∂22-Feb-89 1127 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Textbook on Kolmogorov Complexity: in the making
C03066 00555 ∂22-Feb-89 1209 STAGER@Score.Stanford.EDU 1989/90 Courses and Degrees
C03067 00556 ∂22-Feb-89 1327 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu CDOOD 89 - CFP
C03079 00557 ∂22-Feb-89 1336 X3J13-mailer recent sent to wrong mailing list
C03137 00558 ∂22-Feb-89 1337 X3J13-mailer cs proposal part1 of 3
C03187 00559 ∂22-Feb-89 1338 X3J13-mailer cs proposal part 2 of 3
C03228 00560 ∂22-Feb-89 1339 X3J13-mailer cs proposal part 3 of 3
C03276 00561 ∂22-Feb-89 1432 @Score.Stanford.EDU:gio@sumex-aim.stanford.edu A Proposal to Change Initial Student Support
C03279 00562 ∂22-Feb-89 1515 HEMENWAY@Score.Stanford.EDU Super-stars
C03281 00563 ∂22-Feb-89 1545 hyde@csli.Stanford.EDU CSLI Calendar, Feb 23, 4:17
C03289 00564 ∂22-Feb-89 1630 X3J13-mailer cs proposal part 3 of 3
C03291 00565 ∂22-Feb-89 1633 @Score.Stanford.EDU:katiyar@polya.Stanford.EDU WINTER POTLUCK REMINDER
C03295 00566 ∂22-Feb-89 1707 X3J13-mailer Re: cs proposal part 3 of 3
C03297 00567 ∂22-Feb-89 1713 X3J13-mailer cs proposal straw vote
C03305 00568 ∂22-Feb-89 1714 X3J13-mailer cs proposal
C03306 00569 ∂22-Feb-89 1713 X3J13-mailer cs proposal errata
C03308 00570 ∂23-Feb-89 0029 @Score.Stanford.EDU:cheriton@Pescadero.Stanford.EDU Re: A Proposal to Change Initial Student Support
C03311 00571 ∂23-Feb-89 0318 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: A Proposal to Change Initial Student Support
C03313 00572 ∂23-Feb-89 1143 @Score.Stanford.EDU:winograd@loire.stanford.edu Undergraduate committee meeting next Wed, March 1, 4:30pm
C03319 00573 ∂23-Feb-89 1212 @Score.Stanford.EDU:gio@sumex-aim.stanford.edu Re: A Proposal to Change Initial Student Support
C03322 00574 ∂23-Feb-89 1251 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU
C03323 00575 ∂23-Feb-89 1452 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu [AS.BTH@Forsythe.Stanford.EDU: AFOSR URI BAA]
C03338 00576 ∂23-Feb-89 1620 @polya.Stanford.EDU:tah@linz MTC Seminar
C03340 00577 ∂23-Feb-89 2027 @polya.Stanford.EDU:plotkin@goblin.Stanford.EDU Next AFLB - Tuesday, February 28, 4:15pm.
C03344 00578 ∂24-Feb-89 0829 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Next Week's Faculty Lunch
C03346 00579 ∂24-Feb-89 1033 @Score.Stanford.EDU:pratt@chehalis.stanford.edu CSD potluck this Sunday
C03350 00580 ∂24-Feb-89 1426 X3J13-mailer Issue: EXTENTIONS-POSITION
C03357 00581 ∂24-Feb-89 1429 @Score.Stanford.EDU:gio@sumex-aim.stanford.edu Re: A Proposal to Change Initial Student Support
C03359 00582 ∂24-Feb-89 1437 X3J13-mailer Issue: EXTRA-RETURN-VALUES
C03362 00583 ∂24-Feb-89 1439 X3J13-mailer Issue: UNSPECIFIED-DATATYPES
C03367 00584 ∂24-Feb-89 1439 X3J13-mailer Issue: MACRO-AS-FUNCTION
C03371 00585 ∂24-Feb-89 1439 X3J13-mailer Issue: UNSOLICITED-MESSAGES
C03375 00586 ∂24-Feb-89 1524 TAJNAI@Score.Stanford.EDU Important dates for 1990
C03378 00587 ∂24-Feb-89 1609 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu ADVANCE PROGRAM FOR STOC '89
C03421 00588 ∂25-Feb-89 0941 LOGMTC-mailer Logic Seminar
C03424 00589 ∂26-Feb-89 1350 @Score.Stanford.EDU:Mailer@SAIL.Stanford.EDU
C03427 00590 ∂26-Feb-89 1446 hoffman@csli.Stanford.EDU The Symbolic Systems Forum, March 3rd
C03430 00591 ∂26-Feb-89 2018 @Score.Stanford.EDU,@polya.Stanford.EDU:coraki!pratt@Sun.COM potluck report
C03433 00592 ∂27-Feb-89 0207 @Score.Stanford.EDU:lam@k2.Stanford.EDU Re: A Proposal to Change Initial Student Support
C03435 00593 ∂27-Feb-89 0217 X3J13-mailer Issue: EXTRA-SYNTAX
C03438 00594 ∂27-Feb-89 0218 X3J13-mailer Issue: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS
C03443 00595 ∂27-Feb-89 0255 X3J13-mailer Review schedule reminder
C03447 00596 ∂27-Feb-89 0851 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu faculty meetings
C03451 00597 ∂27-Feb-89 0917 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu STOC Errata and Manuscripts
C03454 00598 ∂27-Feb-89 0922 @Score.Stanford.EDU:golub@na-net.stanford.edu Re: faculty meetings
C03460 00599 ∂27-Feb-89 1005 GENESERETH@Score.Stanford.EDU Re: faculty meetings
C03462 00600 ∂27-Feb-89 1009 @Score.Stanford.EDU:dill@amadeus.Stanford.EDU potluck
C03464 00601 ∂27-Feb-89 1045 @Score.Stanford.EDU:jcm@ra.stanford.edu potluck
C03466 00602 ∂27-Feb-89 1050 @Score.Stanford.EDU:winograd@loire.stanford.edu potluck
C03471 00603 ∂27-Feb-89 1100 TAJNAI@Score.Stanford.EDU Re: potluck
C03473 00604 ∂27-Feb-89 1106 TAJNAI@Score.Stanford.EDU Call for IBM fellowship nominees
C03475 00605 ∂27-Feb-89 1101 X3J13-mailer characters and conformance
C03478 00606 ∂27-Feb-89 2357 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu LICS-89
C03500 00607 ∂28-Feb-89 0733 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Today's Faculty Lunch
C03502 00608 ∂28-Feb-89 0816 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu The ?What Exit? seminar series
C03511 00609 ∂28-Feb-89 0854 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu fac mtg
C03515 00610 ∂28-Feb-89 0956 X3J13-mailer agenda items, registration
C03520 00611 ∂28-Feb-89 1128 misha@polya.Stanford.EDU reminder: AFLB TODAY!
C03523 00612 ∂28-Feb-89 1347 X3J13-mailer cs proposal
C03524 00613 ∂01-Mar-89 0611 @Score.Stanford.EDU:op@polya.Stanford.EDU The rec.humor.funny controversy
C03530 00614 ∂01-Mar-89 0758 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Today's Faculty Meeting
C03532 00615 ∂01-Mar-89 0802 @Score.Stanford.EDU:chandler@polya.Stanford.EDU I can't believe I did that.....
C03534 00616 ∂01-Mar-89 1109 X3J13-mailer Section 1.7
C03543 00617 ∂01-Mar-89 1111 X3J13-mailer Section 5.2
C03558 00618 ∂01-Mar-89 1136 X3J13-mailer Section 1.5
C03565 00619 ∂01-Mar-89 1138 X3J13-mailer Section 1.6
C03600 00620 ∂01-Mar-89 1159 X3J13-mailer New versions of standard files available
C03603 00621 ∂01-Mar-89 1203 X3J13-mailer Section 1.3
C03607 00622 ∂01-Mar-89 1207 X3J13-mailer Section 2.1
C03613 00623 ∂01-Mar-89 1232 X3J13-mailer Section 1.1
C03624 00624 ∂01-Mar-89 1232 X3J13-mailer Section 1.2
C03626 00625 ∂01-Mar-89 1234 X3J13-mailer Section 1.4
C03632 00626 ∂01-Mar-89 1240 X3J13-mailer Section 5.3
C03645 00627 ∂01-Mar-89 1243 X3J13-mailer Section 5.4
C03664 00628 ∂01-Mar-89 1257 X3J13-mailer cs proposal and straw vote
C03677 00629 ∂01-Mar-89 1305 X3J13-mailer Section 1.7
C03681 00630 ∂01-Mar-89 1326 littell@polya.Stanford.EDU Spring Quarter RA appointments
C03683 00631 ∂01-Mar-89 1335 X3J13-mailer Re: Section 1.7
C03686 00632 ∂01-Mar-89 1404 @Score.Stanford.EDU:winograd@loire.stanford.edu Clancy and undergraduate teaching
C03693 00633 ∂01-Mar-89 1432 @Score.Stanford.EDU:wab@sumex-aim.stanford.edu rec.humor.funny, CSD students
C03701 00634 ∂01-Mar-89 1517 @polya.Stanford.EDU:tah@linz Theory Faculty Candidate
C03703 00635 ∂01-Mar-89 1526 X3J13-mailer minor comments on letter ballot material
C03711 00636 ∂01-Mar-89 1622 misha@polya.Stanford.EDU AFLB tomorrow!
C03715 00637 ∂01-Mar-89 1748 @Score.Stanford.EDU:hayes@arisia.xerox.com rec.humor.funny, CSD students
C03721 00638 ∂01-Mar-89 1853 X3J13-mailer Re: minor comments on letter ballot material
C03725 00639 ∂01-Mar-89 2340 X3J13-mailer Section 2.2, part 1
C03765 00640 ∂01-Mar-89 2355 X3J13-mailer Section 2.2 - part 2
C03802 00641 ∂02-Mar-89 0008 X3J13-mailer Section 2.2 - part 3
C03819 00642 ∂02-Mar-89 0731 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Cryptography textbook
C03821 00643 ∂02-Mar-89 0834 X3J13-mailer Section 2.2 - part 4
C03845 00644 ∂02-Mar-89 0905 X3J13-mailer Section 2.2 - part 5
C03926 00645 ∂02-Mar-89 0928 X3J13-mailer forwarding note from gregor from larry
C03936 00646 ∂02-Mar-89 0928 X3J13-mailer forwarding mail from gray
C03947 00647 ∂02-Mar-89 0930 X3J13-mailer cs proposal comments
C03948 00648 ∂02-Mar-89 0929 X3J13-mailer cs proposal comments
C03959 00649 ∂02-Mar-89 1000 X3J13-mailer Re: cs proposal and straw vote
C03964 00650 ∂02-Mar-89 1151 X3J13-mailer Re: cs proposal comments
C03967 00651 ∂02-Mar-89 1421 emma@csli.Stanford.EDU CSLI Calendar, 2 March, 4:18
C03973 00652 ∂02-Mar-89 1502 chandler@polya.Stanford.EDU Test
C03974 00653 ∂02-Mar-89 1510 chandler@polya.Stanford.EDU Another test
C03975 00654 ∂02-Mar-89 1632 X3J13-mailer minor comments on the character proposal
C03979 00655 ∂02-Mar-89 1729 @polya.Stanford.EDU:tah@linz MTC Seminar
C03980 00656 ∂02-Mar-89 1819 @Score.Stanford.EDU:jle@Orange.stanford.edu CS Colloquium
C03984 00657 ∂02-Mar-89 1831 @Score.Stanford.EDU:jle@Orange.stanford.edu CS Colloquium
C03988 00658 ∂02-Mar-89 1909 X3J13-mailer cs proposal and straw vote
C03993 00659 ∂02-Mar-89 1929 X3J13-mailer answer to request for comments on comments on comments on characters
C04004 00660 ∂02-Mar-89 1941 CL-Characters-mailer Really about TYPEP failures: Comments on the Character proposal dated January 1, 1989
C04007 00661 ∂02-Mar-89 2119 LOGMTC-mailer Logic seminar
C04010 00662 ∂03-Mar-89 0004 X3J13-mailer cs comments
C04015 00663 ∂03-Mar-89 0726 @Score.Stanford.EDU:tom@polya.Stanford.EDU NeXT Machine moving
C04017 00664 ∂03-Mar-89 0913 X3J13-mailer cs comments
C04024 00665 ∂03-Mar-89 1006 X3J13-mailer Issue: ERROR-TERMINOLOGY
C04036 00666 ∂03-Mar-89 1032 @polya.Stanford.EDU:tah@linz Theory Faculty Candidate
C04038 00667 ∂03-Mar-89 1127 chandler@polya.Stanford.EDU CSD Retreat
C04040 00668 ∂03-Mar-89 1130 X3J13-mailer Re: Section 1.7
C04042 00669 ∂03-Mar-89 1202 X3J13-mailer Common Lisp
C04045 00670 ∂03-Mar-89 1221 X3J13-mailer KMP's personal comments on 22-Feb-89 Character Proposal
C04069 00671 ∂03-Mar-89 1226 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Final Program-Complexity Symposium
C04085 00672 ∂03-Mar-89 1333 @polya.Stanford.EDU:hayes@arisia.xerox.com CSD Retreat
C04087 00673 ∂03-Mar-89 1427 X3J13-mailer Re: Issue: ERROR-TERMINOLOGY
C04091 00674 ∂03-Mar-89 1539 X3J13-mailer What is a FUNCTION?
C04095 00675 ∂03-Mar-89 1548 X3J13-mailer Error Terminology
C04103 00676 ∂03-Mar-89 1632 X3J13-mailer Re: Issue: ERROR-TERMINOLOGY
C04107 00677 ∂03-Mar-89 1704 X3J13-mailer Issue: ERROR-TERMINOLOGY
C04109 00678 ∂04-Mar-89 1159 X3J13-mailer Error Terminology
C04111 00679 ∂05-Mar-89 1521 hoffman@csli.Stanford.EDU the Symbolic Systems Forum, March 10th.
C04114 00680 ∂06-Mar-89 0838 TAJNAI@Score.Stanford.EDU nominations are closed
C04115 00681 ∂06-Mar-89 0849 @Score.Stanford.EDU:chandler@polya.Stanford.EDU 3-7 Faculty Lunch
C04117 00682 ∂06-Mar-89 1004 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: Cryptography textbook
C04120 00683 ∂06-Mar-89 1008 STAGER@Score.Stanford.EDU Spring TA Appoitments
C04123 00684 ∂06-Mar-89 1038 edith@polya.Stanford.EDU faculty candidate visit
C04125 00685 ∂06-Mar-89 1114 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Bar-Ilan Symposium on Foudations of Artificial Intelligence --
C04133 00686 ∂06-Mar-89 1124 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Crypto '89 -- Final Call for Papers
C04144 00687 ∂06-Mar-89 1130 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: Cryptography textbook
C04153 00688 ∂06-Mar-89 1133 X3J13-mailer Re: KMP's personal comments on 22-Feb-89 Character Proposal
C04155 00689 ∂06-Mar-89 1322 X3J13-mailer Re: minor comments on letter ballot material
C04159 00690 ∂06-Mar-89 1348 X3J13-mailer Feb. 21 Letter Ballot: editorial issues
C04165 00691 ∂06-Mar-89 1355 X3J13-mailer minor comments on letter ballot material
C04168 00692 ∂06-Mar-89 1435 @Score.Stanford.EDU:andy@Gang-of-Four.Stanford.EDU CS student vote on William A. Brown's Statement
C04171 00693 ∂06-Mar-89 1449 X3J13-mailer Re: cs proposal and straw vote
C04177 00694 ∂06-Mar-89 1453 X3J13-mailer Re: cs proposal comments
C04182 00695 ∂06-Mar-89 1506 BSCOTT@Score.Stanford.EDU Univ. Travel Task Force
C04185 00696 ∂06-Mar-89 1512 BSCOTT@Score.Stanford.EDU American Express
C04186 00697 ∂06-Mar-89 1527 misha@polya.Stanford.EDU AFLB tomorrow!
C04189 00698 ∂06-Mar-89 1538 X3J13-mailer Re: cs proposal and straw vote
C04192 00699 ∂06-Mar-89 1627 X3J13-mailer cs proposal straw vote
C04204 00700 ∂06-Mar-89 1714 X3J13-mailer Review schedule reminder
C04206 00701 ∂06-Mar-89 1755 @Score.Stanford.EDU:marty@cis.Stanford.EDU Univ. Travel Task Force
C04208 00702 ∂07-Mar-89 0254 X3J13-mailer clarification
C04211 00703 ∂07-Mar-89 1011 STAGER@Score.Stanford.EDU Tau Beta Pi
C04213 00704 ∂07-Mar-89 1011 debra@russell.Stanford.EDU REMINDER-EVENING SEMINAR
C04215 00705 ∂07-Mar-89 1126 emma@csli.Stanford.EDU CSLI Calendar correction
C04217 00706 ∂07-Mar-89 1207 HEMENWAY@Score.Stanford.EDU Reports Ready
C04219 00707 ∂07-Mar-89 1334 X3J13-mailer hotel for march meeting
C04220 00708 ∂07-Mar-89 1342 @Score.Stanford.EDU:nilsson@Tenaya Thinking Machines
C04223 00709 ∂07-Mar-89 1403 X3J13-mailer Agenda DRAFT
C04226 00710 ∂07-Mar-89 1427 @Score.Stanford.EDU:NA.PHL@Forsythe.Stanford.EDU Sunrise Club Breakfast
C04228 00711 ∂07-Mar-89 1429 X3J13-mailer registration list
C04233 00712 ∂07-Mar-89 1448 @Score.Stanford.EDU:wheaton@Athena.Stanford.EDU IBM RT
C04235 00713 ∂08-Mar-89 0520 X3J13-mailer Issue: PLUS-ABNORMAL
C04238 00714 ∂08-Mar-89 0523 X3J13-mailer Issue: PLUS-ABNORMAL
C04239 00715 ∂08-Mar-89 1023 STAGER@Score.Stanford.EDU Final Exams
C04242 00716 ∂08-Mar-89 1134 @Score.Stanford.EDU:nilsson@Tenaya faculty meeting
C04245 00717 ∂08-Mar-89 1306 @Score.Stanford.EDU:golub@na-net.stanford.edu NSF visitor
C04248 00718 ∂08-Mar-89 1509 @Score.Stanford.EDU:berglund@polya.Stanford.EDU Ph.D. Student Meeting
C04272 00719 ∂08-Mar-89 1610 misha@polya.Stanford.EDU AFLB tomorrow!
C04275 00720 ∂08-Mar-89 1649 X3J13-mailer February 21 Ballot
C04280 00721 ∂08-Mar-89 1719 emma@csli.Stanford.EDU CSLI Calendar, 9 March, $:19
C04288 00722 ∂08-Mar-89 1741 X3J13-mailer Feb. 21 Letter Ballot: editorial issues
C04293 00723 ∂09-Mar-89 1122 kuder@russell.Stanford.EDU SSP Internship lunch
C04295 00724 ∂09-Mar-89 1340 X3J13-mailer Issue: SUBSETTING-POSITION
C04297 00725 ∂09-Mar-89 1345 X3J13-mailer Issue: EXTENTIONS-POSITION
C04299 00726 ∂09-Mar-89 1349 X3J13-mailer Issue: MACRO-AS-FUNCTION
C04301 00727 ∂09-Mar-89 1350 X3J13-mailer Issue: UNSOLICITED-MESSAGES (Version 2)
C04303 00728 ∂09-Mar-89 1352 X3J13-mailer Issue: UNSPECIFIED-DATATYPES (Version 2)
C04305 00729 ∂09-Mar-89 1357 X3J13-mailer Issue: EXTRA-SYNTAX (Version 4)
C04307 00730 ∂09-Mar-89 1406 X3J13-mailer Issue: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS (Version 3)
C04311 00731 ∂09-Mar-89 1433 X3J13-mailer Issue: EXTRA-SYNTAX (Version 4)
C04314 00732 ∂09-Mar-89 1539 X3J13-mailer Re: Issue: UNSPECIFIED-DATATYPES (Version 2)
C04316 00733 ∂09-Mar-89 1613 TAJNAI@Score.Stanford.EDU IBM Fellowship nominations
C04318 00734 ∂09-Mar-89 1742 GENESERETH@Score.Stanford.EDU phd admissions
C04321 00735 ∂09-Mar-89 1847 animal@Portia.stanford.edu Re: SSP Internship lunch
C04323 00736 ∂09-Mar-89 1914 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu COLLOQUIUM SERIES 88-89, Marist College
C04329 00737 ∂09-Mar-89 2038 LOGMTC-mailer "Categories for the working logician"
C04332 00738 ∂10-Mar-89 2024 LOGMTC-mailer The Alfred Tarski Lectures
C04334 00739 ∂11-Mar-89 1034 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu network meeting announcement for distribution
C04343 00740 ∂11-Mar-89 1139 HEMENWAY@Score.Stanford.EDU Ph.D. Admits
C04350 00741 ∂12-Mar-89 1616 X3J13-mailer Issue: UNSOLICITED-MESSAGES
C04354 00742 ∂13-Mar-89 0714 X3J13-mailer cl-compiler mail
C04356 00743 ∂13-Mar-89 0747 X3J13-mailer issue COMPILED-FUNCTION-REQUIREMENTS, version 4
C04371 00744 ∂13-Mar-89 0748 X3J13-mailer issue COMPILER-DIAGNOSTICS, version 9
C04386 00745 ∂13-Mar-89 0749 X3J13-mailer issue COMPILER-VERBOSITY, version 6
C04393 00746 ∂13-Mar-89 0815 X3J13-mailer issue CONSTANT-COMPILABLE-TYPES, version 8
C04423 00747 ∂13-Mar-89 0821 X3J13-mailer issue CONSTANT-CIRCULAR-COMPILATION, version 7
C04435 00748 ∂13-Mar-89 0824 X3J13-mailer issue CONSTANT-COLLAPSING, version 5
C04442 00749 ∂13-Mar-89 0834 X3J13-mailer issue LOAD-TIME-EVAL, version 11
C04468 00750 ∂13-Mar-89 0837 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU Ullman and NAE
C04470 00751 ∂13-Mar-89 0840 X3J13-mailer Issue: UNSOLICITED-MESSAGES
C04474 00752 ∂13-Mar-89 0853 X3J13-mailer issue MACRO-CACHING, version 2
C04492 00753 ∂13-Mar-89 0855 X3J13-mailer Issue: UNSOLICITED-MESSAGES
C04500 00754 ∂13-Mar-89 0853 X3J13-mailer issue COMPILER-VERBOSITY, version 6
C04502 00755 ∂13-Mar-89 0924 X3J13-mailer issue QUOTE-SEMANTICS, version 2
C04516 00756 ∂13-Mar-89 0929 X3J13-mailer issue SAFE-CODE, version 1
C04522 00757 ∂13-Mar-89 0945 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU faculty lunch
C04524 00758 ∂13-Mar-89 1007 @Score.Stanford.EDU:eaf@sumex-aim.stanford.edu Re: faculty lunch
C04526 00759 ∂13-Mar-89 1014 X3J13-mailer Issue: UNSOLICITED-MESSAGES
C04532 00760 ∂13-Mar-89 1046 X3J13-mailer Issue: UNSOLICITED-MESSAGES
C04534 00761 ∂13-Mar-89 1450 X3J13-mailer **DRAFT** issue CLOS-MACRO-COMPILATION, version 2
C04547 00762 ∂13-Mar-89 1452 X3J13-mailer issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
C04562 00763 ∂13-Mar-89 1514 X3J13-mailer issue COMPILE-FILE-SYMBOL-HANDLING, version 2
C04593 00764 ∂13-Mar-89 1517 X3J13-mailer issue COMPILER-LET-CONFUSION, version 7
C04617 00765 ∂13-Mar-89 1531 X3J13-mailer **DRAFT** issue DEFCONSTANT-NOT-WIRED, version 6
C04627 00766 ∂13-Mar-89 1533 X3J13-mailer issue DEFINE-OPTIMIZER, version 5
C04645 00767 ∂13-Mar-89 1536 X3J13-mailer issue DEFINING-MACROS-NON-TOP-LEVEL, version 8
C04654 00768 ∂13-Mar-89 1545 X3J13-mailer issue EVAL-WHEN-NON-TOP-LEVEL, version 6
C04687 00769 ∂13-Mar-89 1601 X3J13-mailer **DRAFT** issue MACRO-ENVIRONMENT-EXTENT, version 3
C04703 00770 ∂13-Mar-89 1610 X3J13-mailer **DRAFT** issue PROCLAIM-ETC-IN-COMPILE-FILE (version 4)
C04716 00771 ∂13-Mar-89 1622 X3J13-mailer **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
C04745 00772 ∂13-Mar-89 1627 X3J13-mailer issue WITH-COMPILATION-UNIT, version 3
C04755 00773 ∂13-Mar-89 1634 X3J13-mailer summary of active cl-compiler issues
C04764 00774 ∂13-Mar-89 1643 X3J13-mailer issue COMPILER-LET-CONFUSION, version 7
C04767 00775 ∂14-Mar-89 0859 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Faculty Meeting
C04769 00776 ∂14-Mar-89 0911 aaai@sumex-aim.stanford.edu Reminder/Council Mtg
C04771 00777 ∂14-Mar-89 0938 CL-Compiler-mailer issue COMPILER-LET-CONFUSION, version 7
C04776 00778 ∂14-Mar-89 0956 CL-Compiler-mailer issue DEFINE-OPTIMIZER, version 5
C04781 00779 ∂14-Mar-89 1005 CL-Compiler-mailer issue WITH-COMPILATION-UNIT, version 3
C04784 00780 ∂14-Mar-89 1217 CL-Compiler-mailer **DRAFT** issue MACRO-ENVIRONMENT-EXTENT, version 3
C04786 00781 ∂14-Mar-89 1232 CL-Compiler-mailer **DRAFT** issue PROCLAIM-ETC-IN-COMPILE-FILE (version 4)
C04791 00782 ∂14-Mar-89 1310 CL-Compiler-mailer issue DEFINING-MACROS-NON-TOP-LEVEL, version 8
C04795 00783 ∂14-Mar-89 1326 CL-Compiler-mailer issue COMPILE-FILE-SYMBOL-HANDLING, version 2
C04798 00784 ∂14-Mar-89 1340 CL-Compiler-mailer issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
C04800 00785 ∂14-Mar-89 1351 CL-Compiler-mailer issue SAFE-CODE, version 1
C04802 00786 ∂14-Mar-89 1357 CL-Compiler-mailer issue COMPILER-VERBOSITY, version 6
C04804 00787 ∂14-Mar-89 1419 X3J13-mailer Issue: ERROR-NOT-HANDLED (Version 1)
C04810 00788 ∂14-Mar-89 1438 CL-Compiler-mailer issue COMPILER-DIAGNOSTICS, version 9
C04814 00789 ∂14-Mar-89 1505 CL-Cleanup-mailer Issue: ERROR-NOT-HANDLED (Version 1)
C04816 00790 ∂14-Mar-89 1544 CL-Compiler-mailer **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
C04823 00791 ∂14-Mar-89 1555 X3J13-mailer LETTER BALLOT -- Sun Microsystems
C04833 00792 ∂14-Mar-89 1610 X3J13-mailer Re: Issue: UNSOLICITED-MESSAGES
C04836 00793 ∂14-Mar-89 1629 CL-Compiler-mailer issue CONSTANT-COMPILABLE-TYPES, version 8
C04845 00794 ∂14-Mar-89 1636 CL-Compiler-mailer issue CONSTANT-COMPILABLE-TYPES, version 8
C04855 00795 ∂14-Mar-89 1651 CL-Compiler-mailer issue QUOTE-SEMANTICS, version 2
C04858 00796 ∂14-Mar-89 1700 CL-Compiler-mailer issue MACRO-CACHING, version 2
C04861 00797 ∂14-Mar-89 1704 CL-Compiler-mailer issue LOAD-TIME-EVAL, version 11
C04863 00798 ∂14-Mar-89 1722 CL-Compiler-mailer issue CONSTANT-CIRCULAR-COMPILATION, version 7
C04865 00799 ∂14-Mar-89 1731 X3J13-mailer Issue: GENSYM-NAME-STICKINESS (Version 1)
C04871 00800 ∂14-Mar-89 1730 CL-Compiler-mailer issue COMPILED-FUNCTION-REQUIREMENTS, version 4
C04874 00801 ∂14-Mar-89 1722 CL-Compiler-mailer issue CONSTANT-COLLAPSING, version 5
C04877 00802 ∂14-Mar-89 1731 X3J13-mailer Issue: COERCE-INCOMPLETE (Version 3)
C04889 00803 ∂15-Mar-89 0520 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C04904 00804 ∂15-Mar-89 0622 X3J13-mailer BASE-CHARACTER
C04908 00805 ∂15-Mar-89 0636 X3J13-mailer Issue IN-PACKAGE-FUNCTIONALITY (Version 8)
C04922 00806 ∂15-Mar-89 0912 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU candidates
C04924 00807 ∂15-Mar-89 0929 @Score.Stanford.EDU:jcm@ra.stanford.edu efficient use of computers
C04926 00808 ∂15-Mar-89 0924 CL-Characters-mailer BASE-CHARACTER
C04928 00809 ∂15-Mar-89 0948 X3J13-mailer Issue: GENSYM-NAME-STICKINESS (Version 1)
C04930 00810 ∂15-Mar-89 0936 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C04932 00811 ∂15-Mar-89 1016 X3J13-mailer Issue: EXTRA-RETURN-VALUES (Version 2)
C04939 00812 ∂15-Mar-89 1018 X3J13-mailer BASE-CHARACTER
C04941 00813 ∂15-Mar-89 1026 STAGER@Score.Stanford.EDU Grade Sheets
C04942 00814 ∂15-Mar-89 1044 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU ICOT
C04947 00815 ∂15-Mar-89 1051 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU possible faculty meeting
C04949 00816 ∂15-Mar-89 1054 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Yesterday's Faculty Meeting
C04951 00817 ∂15-Mar-89 1131 GENESERETH@Score.Stanford.EDU Re: efficient use of computers
C04953 00818 ∂15-Mar-89 1222 misha@polya.Stanford.EDU AFLB tomorrow!
C04956 00819 ∂15-Mar-89 1227 X3J13-mailer Re: Issue ERROR TERMINOLOGY, dpANS C
C04958 00820 ∂15-Mar-89 1342 HEMENWAY@Score.Stanford.EDU Peterson's Guide Information
C04960 00821 ∂15-Mar-89 1347 @Score.Stanford.EDU:chandler@polya.Stanford.EDU CSD Retreat
C04962 00822 ∂15-Mar-89 1414 aaai@sumex-aim.stanford.edu Symposium Meeting
C04964 00823 ∂15-Mar-89 1417 aaai@sumex-aim.stanford.edu Opps!
C04965 00824 ∂15-Mar-89 1446 X3J13-mailer Issue ERROR TERMINOLOGY
C04970 00825 ∂15-Mar-89 1451 CL-Compiler-mailer Issue SAFE-CODE, version 1
C04972 00826 ∂15-Mar-89 1506 CL-Editorial-mailer Re: Issue ERROR TERMINOLOGY, dpANS C
C04984 00827 ∂15-Mar-89 1553 X3J13-mailer Re: Issue: EXTRA-RETURN-VALUES
C04987 00828 ∂15-Mar-89 1603 X3J13-mailer Feb. 21 letter ballot
C04992 00829 ∂15-Mar-89 1722 X3J13-mailer Bartley's Comments
C04993 00830 ∂15-Mar-89 1747 @polya.Stanford.EDU:tah@linz MTC Seminar
C04997 00831 ∂15-Mar-89 1756 X3J13-mailer Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)
C05000 00832 ∂15-Mar-89 1814 @polya.Stanford.EDU:goldberg@Jinn.stanford.edu Interior study group
C05003 00833 ∂15-Mar-89 1853 X3J13-mailer Re: Issue: EXTRA-RETURN-VALUES
C05006 00834 ∂15-Mar-89 1941 CL-Compiler-mailer issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
C05010 00835 ∂15-Mar-89 2041 @Score.Stanford.EDU:jlh@vsop.Stanford.EDU Re: efficient use of computers
C05012 00836 ∂15-Mar-89 2152 @Score.Stanford.EDU:wheaton@Athena.Stanford.EDU efficient use of computers
C05014 00837 ∂16-Mar-89 0601 X3J13-mailer Re: issue COMPILER-VERBOSITY, version 6
C05017 00838 ∂16-Mar-89 0632 X3J13-mailer Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
C05038 00839 ∂16-Mar-89 0701 @Score.Stanford.EDU:ball@polya.Stanford.EDU efficient use of computers
C05040 00840 ∂16-Mar-89 0713 X3J13-mailer Issue: TIME-ZONE-NON-INTEGER, v.1
C05043 00841 ∂16-Mar-89 0708 CL-Compiler-mailer Re: Issue SAFE-CODE, version 1
C05046 00842 ∂16-Mar-89 0719 X3J13-mailer Re: issue LOAD-TIME-EVAL, version 11
C05049 00843 ∂16-Mar-89 0720 X3J13-mailer Issue: LOAD-TRUENAME (Version 1)
C05058 00844 ∂16-Mar-89 0831 X3J13-mailer Issue DESCRIBE-UNDERSPECIFIED, v.1
C05068 00845 ∂16-Mar-89 0854 X3J13-mailer Issue: CLOS-CONDITIONS (Version 4)
C05083 00846 ∂16-Mar-89 0928 CL-Compiler-mailer Issue SAFE-CODE, version 1
C05086 00847 ∂16-Mar-89 0957 X3J13-mailer Re: Issue ERROR TERMINOLOGY, dpANS C
C05092 00848 ∂16-Mar-89 0958 X3J13-mailer Re: Issue: EXTRA-RETURN-VALUES
C05096 00849 ∂16-Mar-89 1004 @Score.Stanford.EDU:jutta@coyote.stanford.edu faculty candidate visits
C05101 00850 ∂16-Mar-89 0958 CL-Compiler-mailer Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
C05104 00851 ∂16-Mar-89 1040 X3J13-mailer Re: Issue ERROR TERMINOLOGY
C05107 00852 ∂16-Mar-89 1044 X3J13-mailer Issue: CLOSED-STREAM-OPERATION (Version 7)
C05115 00853 ∂16-Mar-89 1051 X3J13-mailer Re: Issue ERROR TERMINOLOGY, dpANS C
C05118 00854 ∂16-Mar-89 0958 X3J13-mailer Issue: TIME-ZONE-NON-INTEGER, v.1
C05120 00855 ∂16-Mar-89 1044 X3J13-mailer Issue: COERCE-INCOMPLETE (Version 3)
C05132 00856 ∂16-Mar-89 1045 X3J13-mailer DRAFT Issue: CONDITION-RESTARTS (Version 1)
C05152 00857 ∂16-Mar-89 1117 CL-Compiler-mailer issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
C05155 00858 ∂16-Mar-89 1146 X3J13-mailer Issue ERROR TERMINOLOGY, dpANS C
C05158 00859 ∂16-Mar-89 1205 X3J13-mailer Issue: TIME-ZONE-NON-INTEGER, v.1
C05161 00860 ∂16-Mar-89 1212 X3J13-mailer Issue: COPY-SYMBOL-COPY-PLIST, v.1
C05165 00861 ∂16-Mar-89 1221 X3J13-mailer Issue DESCRIBE-UNDERSPECIFIED, v.1
C05168 00862 ∂16-Mar-89 1241 X3J13-mailer Issue DYNAMIC-EXTENT: a remark
C05172 00863 ∂16-Mar-89 1212 X3J13-mailer Issue: COPY-SYMBOL-PRINT-NAME, v.2
C05176 00864 ∂16-Mar-89 1212 X3J13-mailer *DRAFT* Issue: DESTRUCTURING-BIND, v.2
C05190 00865 ∂16-Mar-89 1213 X3J13-mailer
C05215 00866 ∂16-Mar-89 1354 X3J13-mailer Issue: DYNAMIC-EXTENT
C05220 00867 ∂16-Mar-89 1356 CL-Compiler-mailer Issue SAFE-CODE, version 1
C05222 00868 ∂16-Mar-89 1418 X3J13-mailer Issue DYNAMIC-EXTENT: a remark
C05226 00869 ∂16-Mar-89 1424 X3J13-mailer Issue: TIME-ZONE-NON-INTEGER, v.1
C05229 00870 ∂16-Mar-89 1436 X3J13-mailer Fatal vesus Harmless
C05237 00871 ∂16-Mar-89 1443 CL-Compiler-mailer Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
C05240 00872 ∂16-Mar-89 1551 X3J13-mailer Issue: COERCE-INCOMPLETE (Version 3)
C05242 00873 ∂16-Mar-89 1603 X3J13-mailer *DRAFT* Issue: DESTRUCTURING-BIND, v.2
C05244 00874 ∂16-Mar-89 1726 X3J13-mailer Issue: MAKE-STRING-FILL-POINTER (Version 1)
C05248 00875 ∂16-Mar-89 1745 X3J13-mailer Issue: EXTRA-RETURN-VALUES
C05251 00876 ∂16-Mar-89 1746 X3J13-mailer Issue: COERCE-INCOMPLETE (Version 3)
C05254 00877 ∂16-Mar-89 1801 X3J13-mailer SYMBOL-MACROLET-SEMANTICS, version 6
C05266 00878 ∂16-Mar-89 2103 X3J13-mailer Issue: EXIT-EXTENT, v.6
C05290 00879 ∂16-Mar-89 2220 X3J13-mailer Issue: FUNCTION-COERCE-TIME (Version 2)
C05307 00880 ∂16-Mar-89 2244 X3J13-mailer Issue: SETF-FUNCTION-VS-MACRO, SETF-PLACES, FUNCTION-NAME, v.1
C05346 00881 ∂16-Mar-89 2254 X3J13-mailer Issue: HASH-TABLE-ACCESS (version 2)
C05356 00882 ∂16-Mar-89 2330 X3J13-mailer Issue: LOAD-OBJECTS (Version 3)
C05378 00883 ∂16-Mar-89 2334 X3J13-mailer Issue LOOP-AND-DISCREPANCY, version 1
C05384 00884 ∂17-Mar-89 0009 X3J13-mailer Issue: REAL-NUMBER-TYPE (version 3)
C05396 00885 ∂17-Mar-89 0817 X3J13-mailer Issue: COERCE-INCOMPLETE (Version 3)
C05400 00886 ∂17-Mar-89 0822 chandler@polya.Stanford.EDU test
C05401 00887 ∂17-Mar-89 0834 X3J13-mailer Issue: LOCALLY-TOP-LEVEL (Version 2)
C05409 00888 ∂17-Mar-89 0854 X3J13-mailer Re: Issue: COERCE-INCOMPLETE (Version 3)
C05411 00889 ∂17-Mar-89 0857 X3J13-mailer Re: Issue: COERCE-INCOMPLETE (Version 3)
C05413 00890 ∂17-Mar-89 0906 @Score.Stanford.EDU:golub@na-net.stanford.edu A High-Tech Research Agenda
C05415 00891 ∂17-Mar-89 0946 @Score.Stanford.EDU:csl@sierra.STANFORD.EDU CSD Faculty Candidate Seminar, March 21, 1989 at 10 a.m.
C05419 00892 ∂17-Mar-89 1041 X3J13-mailer Issue: PACKAGE-FUNCTION-CONSISTENCY, V.3
C05427 00893 ∂17-Mar-89 1223 X3J13-mailer issue SAFE-CODE, version 1
C05429 00894 ∂17-Mar-89 1223 X3J13-mailer **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
C05432 00895 ∂17-Mar-89 1223 X3J13-mailer Issue ERROR TERMINOLOGY
C05438 00896 ∂17-Mar-89 1214 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C05443 00897 ∂17-Mar-89 1246 X3J13-mailer Issue: PACKAGE-FUNCTION-CONSISTENCY, V.3
C05445 00898 ∂17-Mar-89 1257 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C05448 00899 ∂17-Mar-89 1251 CL-Compiler-mailer **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
C05451 00900 ∂17-Mar-89 1254 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C05454 00901 ∂17-Mar-89 1316 X3J13-mailer Issue DYNAMIC-EXTENT: a remark
C05458 00902 ∂17-Mar-89 1356 CL-Compiler-mailer **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
C05461 00903 ∂17-Mar-89 1507 @Score.Stanford.EDU:jutta@coyote.stanford.edu Seminar by Robotics Faculty Candidate
C05465 00904 ∂17-Mar-89 1426 X3J13-mailer CLTL II
C05470 00905 ∂17-Mar-89 1541 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C05474 00906 ∂17-Mar-89 1555 X3J13-mailer Re: Issue: COERCE-INCOMPLETE (Version 3)
C05477 00907 ∂17-Mar-89 1600 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C05479 00908 ∂17-Mar-89 1612 X3J13-mailer Re: Issue: COERCE-INCOMPLETE (Version 3)
C05481 00909 ∂17-Mar-89 1613 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C05484 00910 ∂17-Mar-89 1623 X3J13-mailer Issue: PACKAGE-FUNCTION-CONSISTENCY, V.3
C05487 00911 ∂17-Mar-89 1656 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C05493 00912 ∂17-Mar-89 1758 X3J13-mailer too much mail!
C05496 00913 ∂17-Mar-89 2051 X3J13-mailer March meeting issues and sections
C05505 00914 ∂17-Mar-89 2110 X3J13-mailer Issue: EXTRA-RETURN-VALUES (version 3)
C05507 00915 ∂17-Mar-89 2304 X3J13-mailer Issue: PACKAGE-FUNCTION-CONSISTENCY (version 4)
C05514 00916 ∂18-Mar-89 0137 X3J13-mailer The Cleanup Issue Status List
C05547 00917 ∂19-Mar-89 2015 @Score.Stanford.EDU:jle@Orange.stanford.edu CS Colloquium Reminder
C05551 00918 ∂19-Mar-89 2358 @Score.Stanford.EDU:jcm@ra.stanford.edu Info on Concept 100?
C05553 00919 ∂19-Mar-89 2358 @Score.Stanford.EDU:jcm@ra.stanford.edu Info on Concept 100?
C05555 00920 ∂20-Mar-89 0002 X3J13-mailer X3J13 mailer
C05558 00921 ∂20-Mar-89 0942 @Score.Stanford.EDU:janelin@krakatoa.stanford.edu Seminar by Robotics Faculty Candidate
C05562 00922 ∂20-Mar-89 0959 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Good News
C05563 00923 ∂20-Mar-89 1008 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Last Faculty Lunch - Winter Quarter
C05565 00924 ∂20-Mar-89 1229 X3J13-mailer Re: Fatal vesus Harmless
C05570 00925 ∂20-Mar-89 1246 @Score.Stanford.EDU:jle@Orange.stanford.edu Mailer Error
C05572 00926 ∂20-Mar-89 1315 CL-Compiler-mailer issue COMPILER-VERBOSITY, version 6
C05574 00927 ∂21-Mar-89 0847 debra@russell.Stanford.EDU REMINDER-EVENING SEMINAR
C05576 00928 ∂21-Mar-89 1106 debra@russell.Stanford.EDU C O R R E C T I O N - REMINDER-EVENING SEMINAR
C05578 00929 ∂21-Mar-89 1453 X3J13-mailer Issue: PATHNAME-COMPONENT-VALUE (version 1)
C05593 00930 ∂21-Mar-89 1455 X3J13-mailer Issue: COMMON-TYPE (version 1)
C05597 00931 ∂21-Mar-89 1458 X3J13-mailer Issue: COMPLEX-RATIONAL-RESULT (version 1)
C05602 00932 ∂21-Mar-89 1500 X3J13-mailer Issue: HASH-TABLE-SIZE (version 1)
C05607 00933 ∂21-Mar-89 1629 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
C05622 00934 ∂21-Mar-89 1732 CL-Compiler-mailer **DRAFT** issue CLOS-MACRO-COMPILATION, version 2
C05626 00935 con-Mar-89 2048 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
C05669 ENDMK
C⊗;
∂12-Dec-88 1528 X3J13-mailer Issue: TAILP-NIL (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 15:27:54 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 15:18:20 PST
Date: 12 Dec 88 15:17 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: TAILP-NIL (Version 5)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-151820-5387@Xerox>
!
Issue: TAILP-NIL
References: TAILP (p275)
Category: CLARIFICATION/CHANGE
Edit History: 13-Sep-88, version 1 by Walter van Roggen,
13-Sep-88, version 2 by Pitman
18-Oct-88, version 3 by van Roggen (just one proposal)
01-Dec-88, version 4 by Pitman (minor edits per discussion)
9-Dec-88, Version 5 by Masinter (clarify EQL)
Problem Description:
CLtL (p275) specifies TAILP as:
TAILP sublist list [Function]
This predicate is true if SUBLIST is a sublist of LIST (i.e.,
one of the conses that makes up LIST); otherwise, it is false.
Another way to look at this is that TAILP is true if
(NTHCDR n list) is SUBLIST, for some value of N. See LDIFF.
Two implementations of this definition might be:
(defun tailp (sublist list) ;Definition "A"
(do ((list list (cdr list)))
((endp list) nil)
(if (eql sublist list)
(return t))))
(defun tailp (sublist list) ;Definition "B"
(do ((list list (cdr list)))
((atom list) (eql list sublist))
(if (eql sublist list)
(return t))))
They differ only in their treatment of the atomic case.
At issue is the fact that () is a list, and hence some would
argue that it is a sublist of all other lists. On the other hand,
the definition of TAILP seems to imply that being a cons is a
necessary precondition of being a "sublist".
Also at issue is the question of whether dotted lists are permissible
second arguments.
Proposal (TAILP-NIL:T):
Strike any text in the definition of TAILP which suggests that a
sublist must be a cons.
Clarify that (TAILP sublist list) returns true iff (NTHCDR n list) is
sublist for some value of n, and false otherwise.
Note, however, that since the list may be dotted, so the end test
used by TAILP must be ATOM, not ENDP. That is, if (TAILP x l)
returns true, it means there was n such that (NTHCDR n list) would
return x; however, it doesn't follow that if TAILP returns false,
it is safe to go blithely NTHCDR's into the list looking for it,
since the list might be dotted and NTHCDR might hit bad data.
Note that TAILP uses EQL or equivalent to compare
sublist to list in the case where sublist is a number, etc.
Rationale:
This is more consistent with the definition of LDIFF, which
gives a useful meaning to arbitrary atomic SUBLIST arguments.
This gives a more elegant definition of SUBLIST, allowing it to
refer to any list -- including the empty list -- which is a
part of another list.
Some reasons for preferring an ATOM check to ENDP include:
- The name TAILP suggests tails, not sublists. Some users might
expect this distinction to mean that data more general than
proper sublists.
- Making TAILP require lists limits its usefulness. If we did
not make this choice, some users would end up having to write
their own extended TAILP which we could just as well have
provided compatibly.
- TAILP is not considered to be used frequently enough in code
that the minor loss in speed to an ATOM check is worth the
lost functionality. Indeed, expanding the scope of its
capabilities may lead to more uses for TAILP.
- Other operators (eg, APPEND) have recently been extended to
treat dotted lists in an interesting way because users have
expressed a desire for this. As such, this change is
culturally consistent.
- Some implementations already support this feature, and the
wording in CLtL is sufficiently ambiguous that some users
might think it appropriate to depend on the feature. In the
absence of compelling efficiency reasons to the contrary,
we should lean toward extending some implementations rather
than tightening others in our efforts to achieve cross-dialect
consistency.
Examples:
#1: (LET ((X '(B C))) (TAILP X (CONS 'A X)))
should return T in all implementations.
#2: (TAILP '(X Y) '(A B C))
should return NIL in all implementations.
#3: (TAILP '() '(A B C))
returns T under this proposal.
#4: (TAILP 3 '(A B C))
returns NIL under this proposal.
#5: (TAILP 3 '(A B C . 3))
returns T under this proposal.
#6: (TAILP '(X Y) '(A B C . 3))
returns NIL under this proposal.
Current Practice:
Symbolics Genera is consistent with TAILP-NIL:T.
Neither Lucid nor VAX LISP currently implements TAILP-NIL:T.
VAX LISP effectively implements definition "A" from the
Problem Description above.
Cost to Implementors:
An implementation of TAILP-NIL:T is given as Definition "B" in the
problem description.
Some implementations might have compiler optimizers for these definitions
as well, so a slight amount of additional effort might be required.
Cost to Users:
Given that current practice varies widely on the disputed case,
this is unlikely to have a practical effect on existing portable code.
Benefits:
Avoids unnecessary incompatibilities between implementations.
Non-Benefits:
Slows down TAILP slightly in some implementations because ENDP is
potentially faster than ATOM.
Discussion:
This issue was first raised in ">GLS>clarifications.text" of 12/06/85.
It recommended an earlier proposal, TAILP-NIL:NIL, which is effectively
equivalent to Definition "A" from the Problem Description.
Pitman introduced TAILP-NIL:T as an alternative, arguing that the
definition TAILP-NIL:NIL offered no practical value to programmers
in the disputed situations, while TAILP-NIL:T was of arguable usefulness.
Pitman and van Roggen support TAILP-NIL:T.
It was suggested more than once by more than one cleanup
committee member that we remove TAILP from the language
"since almost nobody uses it".
∂12-Dec-88 1601 X3J13-mailer Re: Issue: TEST-NOT-IF-NOT (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 16:01:36 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 12 DEC 88 15:55:20 PST
Date: 12 Dec 88 15:53 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: TEST-NOT-IF-NOT (Version 3)
In-reply-to: my message of 9 Dec 88 15:26 PST <881209-153026-1243@Xerox>
To: X3J13@sail.stanford.edu
Message-ID: <881212-155520-5496@Xerox>
The writeup in this issue was mislabelled Version 2. In fact, it was
Version 3, 1 Dec 88, Masinter (add comments).
The ballot will reflect this.
∂12-Dec-88 1609 X3J13-mailer Issue: TYPE-OF-UNDERCONSTRAINED (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 16:09:45 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 12 DEC 88 16:01:09 PST
Date: 12 Dec 88 16:00 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: TYPE-OF-UNDERCONSTRAINED (Version 3)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-160109-5511@Xerox>
As JonL pointed out, Version 2 was missing a "not" in
a key sentence in the proposal.
!
Forum: Cleanup
Issue: TYPE-OF-UNDERCONSTRAINED
References: TYPE-OF (CLtL)
88-002R (Class-of)
88-005, p 43f, Condition system types
Related issues: SUBTYPEP-TOO-VAGUE
DATA-TYPE-HIERARCHY-UNDERSPECIFIED
FUNCTION-TYPE
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
COERCE-INCOMPLETE
Category: CLARIFICATION/CHANGE
Edit history: Version 1, 1-Dec-88, Masinter
Version 2, 9-Dec-88, Masinter
Version 3, 12-Dec-88, Masinter (fix "egregious bug")
Problem description:
The specification of TYPE-OF in CLtL is so weak as to leave it
nearly useless, if any implementor actually took the specification
seriously.In particular, there are almost no constraints on the
value that TYPE-OF might return for any of the built in
types. The only constraint placed is that for objects created by the
constructor function of DEFSTRUCT, the result of TYPE-OF is the name of the
defstruct.
This means that implementations could return T for all other objects.
Proposal (TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS):
Specify that the result of TYPE-OF satisfies the following:
(a) For any object for which (typep object built-in-type) is true when
built-in-type is one of
INTEGER, RATIO, FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT, COMPLEX, NUMBER
SYMBOL,
STRING, VECTOR, ARRAY,
CONS,
STREAM, PACKAGE, CHARACTER, FUNCTION, READTABLE, HASH-TABLE, PATHNAME,
CONDITION, RESTART,
the result of TYPE-OF will be a type specifier for which
(subtypep (type-of object) built-in-type) returns T T, i.e., either the
build-in-type or a subtype of it (a subtype that the
implementation's SUBTYPEP can recognize.)
(b) For all objects, (TYPEP object (TYPE-OF object)) will be true.
(this implies that it will not be NIL, since no
object is of type NIL.)
(c) will not be a MEMBER type specifier, or T.
For objects created by the "constructor" function of a structure
defined with DEFSTRUCT without a :TYPE option, TYPE-OF
will return the structure name.
For objects created by MAKE-INSTANCE, giving a named
class, TYPE-OF will return the class name of the class.
For objects which are instances of anonymous classes (i.e., where
(CLASS-NAME (CLASS-OF object)) is NIL), the result of TYPE-OF should be the
class object itself.
(The CLOS specification has already specified that class objects are
acceptable wherever type specifiers are, and in particular, as input to
SUBTYPEP and TYPEP.)
This proposal is intended to be consistent with 88-002R,
and not to conflict with any of the definitions in that document.
Examples:
It is legal for (TYPE-OF "abc") to return (SIMPLE-STRING 3), or just
STRING. It is legal for (TYPE-OF 112312) to return SI:MEDIUM-SIZE-FIXNUM,
as long as (SUBTYPEP 'SI:MEDIUM-SIZE-FIXNUM 'INTEGER).
Given:
(defvar *foo* (make-array 5 :element-type t))
(class-name (class-of *foo*)) => SIMPLE-VECTOR
It is legal for
(type-of *foo*) => (SIMPLE-VECTOR 5)
Rationale:
The original specification for "TYPE-OF" was written to allow
implementation freedom, but the wording is in fact more vague than was
intended.
Current practice:
Most Common Lisp implementations seem to implement the proposal, at least
for the types we've tried them on.
Cost to Implementors:
Even if there are implementations that do not currently implement the
proposal, the required changes for them are likely to be minimal.
Cost to Users:
Apparently none.
Cost of non-adoption:
TYPE-OF would remain potentially inconsistent.
Performance impact:
Likely none.
Benefits:
Bring the specification of TYPE-OF in like with its common
implementation, while requiring it to be generally useful.
Esthetics:
Little effect.
Discussion:
Originally, TYPE-OF was concieved as being useful for information display.
CLOS specified CLASS-OF far more precisely, in that it must return exactly
the class of an object. Unless TYPE-OF is removed from the language, it
seems reasonable to require it to be at least as precise as CLASS-OF.
The accepted CLOS specification does not define CLASS-OF
in terms of TYPE-OF, but an earlier draft did.
This proposal presumes the (passed) proposals
DATA-TYPES-HIERARCHY-UNDERSPECIFIED:DISJOINT, FUNCTION-TYPE, and
accomodates the Condition System (version 18) and CLOS.
If ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS does not pass,
and this proposal does pass, it may be that the only way an
implementation can satisfy (TYPEP array (TYPE-OF array))
would be to have (TYPE-OF array) return VECTOR or ARRAY
as appropriate, i.e., with no element type qualification.
It is possible to constrain TYPE-OF further, e.g., to eliminate
the possibility that it might return a non-portable
implementation-specific value. For example,
(TYPE-OF 112312) should not return SI:MEDIUM-SIZE-FIXNUM, but rather some
thing like (SIGNED-BYTE 17) [if that's what SI:MEDIUM-SIZE-FIXNUM means.]
We would like to make this as an implementation recommendation,
however, rather than as a constraint, at this point.
----- End Forwarded Messages -----
∂12-Dec-88 1622 X3J13-mailer Issue: REST-LIST-ALLOCATION (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 16:22:35 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 16:11:10 PST
Date: 12 Dec 88 16:08 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: REST-LIST-ALLOCATION (Version 3)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-161110-5531@Xerox>
Thanks to Will Clinger for getting a last minute revision in.
!
Forum: Cleanup
Issue: REST-LIST-ALLOCATION
References: CLtL pp 107-108 (APPLY)
Related issues: DYNAMIC-EXTENT
Category: CLARIFICATION
Edit history: 8-Dec-88, Version 1 by Masinter
9-Dec-88, Version 2 by Clinger (add rationale, more discussion)
12-Dec-88, Version 3 by Clinger (delete bogus examples)
Problem description:
In the special case of calling a function with an &REST list via APPLY,
Common Lisp fails to specify whether a new copy of the list is freshly
allocated. For example, given
(DEFVAR *MY-LIST* '(A B C))
(DEFUN FOO (&REST X) (EQ X *MY-LIST*))
does
(APPLY #'FOO *MY-LIST*)
return T?
This issue is different from the question of the extent of "rest lists" in
the case when they *are* newly allocated which is indefinite; the issue
DYNAMIC-EXTENT also contains some proposals about extent.
Proposal (REST-LIST-ALLOCATION:NEWLY-ALLOCATED):
Specify that &REST lists are newly allocated in the case when the function
is called via APPLY.
Proposal (REST-LIST-ALLOCATION:MAY-SHARE):
Specify that the value of an &REST parameter is permitted, but not required,
to share (top-level) structure with the last argument to APPLY.
Proposal (REST-LIST-ALLOCATION:MUST-SHARE)
Specify that the value of an &REST parameter is required
to share (top-level) structure with the last argument to APPLY.
>> this needs better spec about how the args match <<
Examples:
(DEFVAR *MY-LIST* '(A B C))
(DEFUN FOO (&REST X) (EQ X *MY-LIST*))
(APPLY #'FOO *MY-LIST*) => T ;on Symbolics systems and probably
; many stock hardware implementations
This implies that
(DEFUN BAR (&REST X) (RPLACA X 'D))
(APPLY #'BAR *MY-LIST*)
*MY-LIST* => (D B C) ;on Symbolics systems and probably many stock
; hardware implementations
Another example: which of the following have the same semantics?
(setq x '(1 2 3))
[1] (apply #'foo 1 2 3 NIL)
[2] (apply #'foo 1 2 (cddr x))
[3] (apply #'foo 1 (cdr x))
[4] (apply #'foo x)
[5] (funcall #'foo 1 2 3)
Under REST-LIST-ALLOCATION:NEWLY-ALLOCATED:
[1]-[5] are equivalent.
Under REST-LIST-ALLOCATION:MAY-SHARE:
Any answer to the question is correct for some conceivable implementation.
Abstracting over implementations, this means that [1]-[5] are pairwise
non-equivalent.
Under REST-LIST-ALLOCATION:MUST-SHARE:
[1]-[4] are pairwise non-equivalent in all implementations. This proposal
leaves open the question of whether [1] is equivalent to [5].
And finally:
Should (defun foo (&rest x) ...)
behave (aside from efficiency) as if it were defined:
(defun foo (&rest G0047) ;Gensym really
(let ((x (copy-list G0047)))
...))
Rationale:
The semantics of APPLY is unclear. In consequence it is impossible
to write portable code that relies on &REST arguments sharing structure
with the last argument to APPLY. Portable code can rely on &REST arguments
*not* sharing structure with the last argument to APPLY, but only by
performing an explicit COPY-LIST on all &REST arguments; this is redundant
and inefficient in implementations where &REST arguments are newly
allocated anyway.
Current practice:
Some implementations always share. Some implementations never share.
A few may share interpreted and not share compiled, or vice versa.
Cost to Implementors:
None for MAY-SHARE, since that is the status quo. Both of the other
proposals entail a significant cost for some implementations.
If MUST-SHARE is adopted, then implementations that don't share structure
may be nearly impossible to convert. If NEWLY-ALLOCATED is adopted, then
implementations that do share will have to insert a call to COPY-LIST
inside either APPLY or &REST list handling, which will slow things down
and may be difficult as well.
Cost to Users:
No matter what, somebody gets hurt. MAY-SHARE means you have to
write awkward and inefficient code if you care. (This is already
the case for portable code.) MUST-SHARE means you have to add
explicit calls to COPY-LIST to code that assumes the contrary.
NEWLY-ALLOCATED means you have to rewrite code that assumes sharing.
Cost of non-adoption:
Great confusion over the issue. A certain amount of awkwardness and
inefficiency would remain inevitable if you want to write portable code.
Performance impact:
MUST-SHARE costs least in consing, but might slow down function call
for some implementations. MAY-SHARE lets implementations pick, has
least impact. NEWLY-ALLOCATED requires consing in cases where it
didn't before.
Benefits:
Less confusion. Improved portability.
Esthetics:
Differing, strongly held opinions.
Discussion:
The Revised3 Report on Scheme specifies that the equivalent of a
&REST argument must be a newly allocated list, to avoid precisely this
problem.
The argument for MUST-SHARE is that copying is inefficient, so
&REST should never cause copying of a list passed to it from APPLY.
Functions that desire a new copy can just call COPY-LIST.
Two arguments for MAY-SHARE are:
1. In no other place does Common Lisp automatically unshare structure,
except when the user is explicitly modifying the structure (as in REMOVE).
Making APPLY automatically unshare would be a semantic wart.
2. If APPLY copies its last argument, recursive programs that receive an
&REST argument and pass it to APPLY become inefficient. A linear time
algorithm can change to a quadratic time algorithm. While the efficiency
could be regained through compiler flow analysis in many cases, it's
better not to put the inefficiency into the language in the first place.
The DYNAMIC-EXTENT proposal would allow &REST lists
that were "newly allocated" to have dynamic extent if they were
to be passed down via APPLY. This puts the burden in the
right place.
Two (closely related) arguments for NEWLY-ALLOCATED:
1. The programmer's model of function calling is simpler: functions
take arguments, and any two calls that pass the same arguments to the
same function are equivalent. The MAY-SHARE and MUST-SHARE proposals
require a model in which functions generally take their arguments in
the form of a list, and the extent to which that list shares structure
with other lists in the system becomes an important part of the
semantics of a function call.
2. It's not only smashing a &rest argument that's a problem, it's
smashing any list that has been given as the last argument to APPLY as
well. Consider the following in an implementation that doesn't copy
the last argument to APPLY when it is passed as a &rest argument:
> (defvar *message*)
*MESSAGE*
> (defun set-message (&rest mess)
(setq *message* mess))
SET-MESSAGE
> (let ((winner (list 'a 'winner)))
(apply #'set-message winner)
(setf (cdr winner) (list 'loser))
winner)
(A LOSER)
Is *message* (A WINNER) or (A LOSER)? (It might be
(#<DTP-LOCATIVE 76123756> #<DTP-ODD-PC 12313453> ...)
but that's a different problem.) This suggests that once a list has
been given as the last argument to APPLY it is no longer OK to modify
it.
Gail Zacharias talked about the common idiom of simply doing a COPY-LIST
on every &rest argument, to insure some normalcy. Her reasoning seems
to bolster the case for those who claim that the current CL semantics
(MAY-SHARE) are deficient:
Subject: &REST Lists
Date: 24 Mar 88 12:23:15 EST (Thu)
From: gz@spt.entity.com (Gail Zacharias)
. . .
If Common Lisp doesn't require unshared &rest lists, then I think
it must provide a declarative version of this idiom so the COPY-LIST can
be portably avoided when it's redundant. Seems to me that the fact that
this is a common case where users find a need for conditionalization
indicates a real deficiency in Common Lisp's specification.
. . .
So we have a responsibility to resolve the very thorny issue
of REST-LIST-ALLOCATION.
∂12-Dec-88 1623 X3J13-mailer Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 16:22:49 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 16:17:33 PST
Date: 12 Dec 88 16:17 PST
Sender: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 2)
From: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <881212-161733-5559@Xerox>
!
Issue: UNREAD-CHAR-AFTER-PEEK-CHAR
References: pp 379, 380 of CLtL
Category: CLARIFICATION
Edit history: Version 1 by Doug Cutting <Cutting.PA@Xerox.COM> on July 29, 1988
Version 2 by Masinter 2-Dec-88
Problem description:
PEEK-CHAR and UNREAD-CHAR are very similar mechanisms. The description of
PEEK-CHAR in CLtL even states that "it is as if one had called READ-CHAR and
then UNREAD-CHAR in succession." But while CLtL prohibits calling UNREAD-CHAR
twice in succession it does not prohibit calling UNREAD-CHAR after PEEK-CHAR.
The obvious implementation of PEEK-CHAR and UNREAD-CHAR (a one-character buffer)
will not work unless this prohibition is present.
Proposal (UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW):
Rewrite the specification so that it is clear that doing either a
PEEK-CHAR or READ-CHAR `commits' all previous characters. UNREAD-CHAR
on any character preceding that which is seen by the PEEK-CHAR (including
those passed over by PEEK-CHAR when `seeking' with a non-NIL first
argument) is not specified.
In particular, the results of calling UNREAD-CHAR after PEEK-CHAR
is unspecified.
Example:
(defun test (&optional (stream *standard-input*))
(let* ((char1a (read-char stream))
(char2a (peek-char nil stream))
(char1b (progn (unread-char char1a stream)
(read-char stream)))
(char2b (read-char stream)))
(list char1a char2a char1b char2b)))
This is not legal, since the PEEK-CHAR for char2a "commits"
the character read by char1a, and so the unread-char is not legal.
Rationale:
PEEK-CHAR and UNREAD-CHAR provide equivalent functionality and it is thus
reasonable for an implementation to implement them in terms of the same
mechanism.
Current practice:
In Xerox Common Lisp, different (non-random-access) stream types behave
differently. One, (TCP/FTP) handled this correctly, while another did not.
In Symbolics Genera, for the Example above:
(test)ab
=> (#\a #\b #\a #\b)
(with-input-from-string (s "abc") (test s))
=> (#\a #\b #\a #\b)
(progn (with-open-file (s "foo.output" :direction :output)
(write-string "abc" s))
(with-open-file (s "foo.output" :direction :input)
(test s)))
Signals an error about unreading #\a when #\b was already unread.
Cost to Implementors:
Presumably none. Implementations which allow this are still correct.
Cost to Users:
Small. I suspect there is very little code which depends upon this working
correctly, as most code uses either PEEK-CHAR or UNREAD-CHAR, but not both.
Cost of non-adoption:
Implementations of sequential streams are forced to be unnecessarily complex in
order to be correct.
Benefits:
Allows simple yet adequately powerful implementation of sequential streams.
Esthetics:
Requires that users have shared, one-char buffer model of how UNREAD-CHAR and
PEEK-CHAR work, rather than two separate one-char buffers.
Discussion:
<none>
∂12-Dec-88 1643 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Call for Papers Workshop on Automatic Verification Methods for
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Dec 88 16:43:10 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA03528; Mon, 12 Dec 88 16:42:22 PDT
Message-Id: <8812130042.AA03528@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Mon, 12 Dec 88 16:42:38 PST
Received: by BYUADMIN (Mailer R2.01) id 2493; Mon, 12 Dec 88 17:24:47 MST
Date: Mon, 12 Dec 88 13:01:54 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Edmund.Clarke%G.GP.CS.CMU.EDU@Forsythe.Stanford.EDU
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Edmund.Clarke%G.GP.CS.CMU.EDU@Forsythe.Stanford.EDU
Subject: Call for Papers Workshop on Automatic Verification Methods for
Finite S
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Call for Papers
Workshop on Automatic Verification Methods for Finite State Systems
Grenoble, France
June 12-14 , 1989
Sponsored by C-cube, the French National Project on Parallelism
This workshop is dedicated to bringing together researchers and practitioners
interested in the development and use of methods tools and theories for
automatic verification of finite state systems. The goal of the workshop is
to compare the various verification methods for finite state systems, and
tools supporting them as assistants of the application designer. Emphasis will
be not only on new research results but also on the applications of existing
results to real verification problems. Special sessions for demonstration
of verification tools will be planned.
Travel support for some participants will be provided. A balanced participation
of researchers and practitioners is expected.
Papers are sollicited on the following topics :
Verification and validation tools for protocols,
Real-time systems,
hardware verification,
Verification methods based on theorem proving, model checking, and
automata based methods,
Verification theories and their applicability.
This list is not exhaustive, and papers in related areas that fit with the
intensions of the workshop will also be considered.
An author may submit a paper by mailing 4 copies of a preliminary version to
either of the program committee members:
E. M. Clarke A. Pnueli J. Sifakis
CMU Weizmann Inst. LGI-IMAG
Computer Sci. Dpt. Rehovot BP 53X
Pittsburgh, PA 15213 Israel 38041 Grenoble cedex
USA France
The preliminary version is limited to a length of 12 double spaced
typed pages. It should provide sufficient detail so that the program
committee can assess the merits of the contribution. The deadline for
the submission of the preliminary version is February 1, 1989. Authors
will be notified of acceptance by March 15, 1989. The final versions
of accepted and invited papers will be published after the workshop.
Researchers who want to attend the workshop, but not present a paper
should notify a member of the program committee as soon as possible.
∂12-Dec-88 1648 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Crypto '89 -- Call for Papers
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Dec 88 16:48:11 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA03811; Mon, 12 Dec 88 16:47:22 PDT
Message-Id: <8812130047.AA03811@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Mon, 12 Dec 88 16:47:54 PST
Received: by BYUADMIN (Mailer R2.01) id 2688; Mon, 12 Dec 88 17:26:02 MST
Date: Mon, 12 Dec 88 13:05:51 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Kevin S. McCurley" <MCCURLEY%ALMVMA.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Kevin S. McCurley" <MCCURLEY%ALMVMA.BITNET@forsythe.stanford.edu>
Subject: Crypto '89 -- Call for Papers
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
---------------------------------------------------------------------
CRYPTO '89
CALL FOR PAPERS
The Ninth Annual Crypto Conference sponsored by the International
Association for Cryptologic Research (IACR) in cooperation with the
IEEE Computer Society Technical Committee on Security and Privacy, and
the Computer Science Department of the University of California, Santa
Barbara, will be held on the campus of the University of California,
Santa Barbara, on August 20-24, 1989. Original research papers and
technical expository talks are solicited on all practical and
theoretical aspects of cryptology. It is anticipated that some talks
may also be presented by special invitation of the Program Committee.
INSTRUCTIONS FOR AUTHORS: Authors are requested to send ten copies of
a detailed abstract (not a full paper) by March 17, 1989, to the
Program Chairperson at the address given below. Abstracts should
contain sufficient detail, as well as references to and comparisons
with relevant extant work, to enable Program Committee members to
appreciate their merits. It is recommended that abstracts start with a
succinct statement of the problem and discussion of its significance
and relevance to cryptology, appropriate for a non-specialist reader.
In order to facilitate blind refereeing, the names of authors and
their affiliations should only appear on the cover page of the paper;
it should be possible to remove this page and send the papers to
Program Committee members. Limits of 10 double-spaced pages and 2500
words (not counting the bibliography and the cover page) are placed on
all abstracts. If the authors believe that more details are essential
to substantiate the main claims of the paper, they are asked to
include a clearly marked appendix that will be read at the discretion
of the Program Committee. Abstracts that significantly deviate from
these guidelines risk rejection without consideration of their merits.
Abstracts received after the March 17 deadline WILL NOT BE
CONSIDERED, unless they are postmarked not later than March 13 and
arrive a reasonable time thereafter. Authors will be informed of
acceptance or rejection in a letter mailed not later than May 26.
A compilation of all abstracts accepted will be available at the
conference. Authors of accepted papers will be given until July 14,
1989 to submit revised abstracts for this compilation. Complete
conference proceedings will be published in Springer-Verlag's Lecture
Notes in Computer Science series at a later date. The Program
Committee will consider abstracts that have also been submitted to
other conferences. However, if a submission is accepted for
presentation at more than one conference, the authors may present the
results more than once, but may publish them in at most one
proceedings.
The Program Committee consists of
Josh Benaloh (University of Toronto)
Russell Brand (Special session chairperson, Lawrence Livermore Laboratory)
Gilles Brassard (Committee chairperson, Universite de Montreal)
Claude Crepeau (Massachusetts Institute of Technology)
Whitfield Diffie (Bell Northern Research)
Joan Feigenbaum (AT&T Bell Laboratories)
James Massey (ETH Zentrum, Zurich)
Jim Omura (Cylink Corporation)
Gustavus Simmons (Sandia National Laboratories)
Scott Vanstone (University of Waterloo)
Send abstracts to the For other information,
program chairperson: contact the general chairman:
---------------------------- ---------------------------
Gilles Brassard, Crypto '89 Kevin McCurley
Departement IRO IBM Research, K53/802
Universite de Montreal 650 Harry Road
C.P. 6128, Succursale ``A'' San Jose, CA 95120-6099
Montreal (Quebec) U.S.A.
CANADA H3C 3J7 telephone: (408) 927-1708
telephone: (514) 343-6807 Internet: mccurley@ibm.com
email: brassard@iro.umontreal.ca Bitnet: mccurley@almvma
∂12-Dec-88 1735 X3J13-mailer CommonLisp/C interface
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 17:35:03 PST
Received: from fafnir.think.com by Think.COM; Mon, 12 Dec 88 19:47:10 EST
Return-Path: <kahle@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 12 Dec 88 20:33:03 EST
Received: from ungar.think.com by verdi.think.com; Mon, 12 Dec 88 20:31:35 EST
Received: by ungar.think.com; Mon, 12 Dec 88 20:32:57 EST
Date: Mon, 12 Dec 88 20:32:57 EST
From: kahle@Think.COM
Message-Id: <8812130132.AA13377@ungar.think.com>
To: x3j13@sail.stanford.edu
Subject: CommonLisp/C interface
We at Thinking Machines have been using Common Lisp as a system programming
language. The principle features that are missing from CommonLisp for this
purpose is the Lisp/C interface specification. This deficiency makes our
code non-portable. On the other hand, Lucid has provided a good set of
functions that have gotten better in each release. To start the
discussion:
I propose the Common Lisp committee adopt the Lucid 3.0 foreign function
interface as the Common Lisp standard.
-brewster
Brewster@think.com
∂12-Dec-88 1755 X3J13-mailer Issue: TAILP-NIL (Version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Dec 88 17:55:38 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 507602; Mon 12-Dec-88 20:55:04 EST
Date: Mon, 12 Dec 88 20:55 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAILP-NIL (Version 5)
To: x3j13@sail.stanford.edu
cc: cl-cleanup@sail.stanford.edu, masinter.pa@Xerox.COM
In-Reply-To: <881212-151820-5387@Xerox>
Message-ID: <19881213015522.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Correction: Contrary to what the current practice section says,
the proposal TAILP-NIL:T is not what Symbolics Genera does. In
fact I know of no implementation that does what the proposal says.
However, I support the proposal anyway, because I think it's the
most consistent with the rest of Common Lisp.
∂12-Dec-88 1838 X3J13-mailer ** BALLOT ** BALLOT ** BALLOT ** BALLOT **
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88 18:38:07 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 18:16:49 PST
Date: 12 Dec 88 18:16 PST
From: masinter.pa@Xerox.COM
to: x3J13@sail.stanford.edu
Subject: ** BALLOT ** BALLOT ** BALLOT ** BALLOT **
Message-ID: <881212-181649-5908@Xerox>
The issues and proposals named below have been mailed to the X3J13 mailing
list. (Hardcopy mail will follow.)
This ballot is "for informational purposes": If there are errors, problems,
or corrections to any of the issues-- especially the late-breaking ones--
please prepare amendments or new versions to bring to the January meeting.
The purpose of the ballot is to help us avoid discussing the
non-controversial issues; the ballot will tell us which issues should be
included in a "block" vote of endorsement/rejection. There will be
opportunity at the January meeting to correct mistakes or review issues, if
there is some belief that they were incorrectly framed, misunderstood, or
should otherwise be reviewed.
For each proposal, please chose one of the following:
[Y]es: adopt the Proposal
[N]o: don't adopt the Proposal
[I]f the following condition holds....
Only adopt the proposal given some precondition
[C]larify the following point & resubmit
You don't understand the proposal (please explain)
[A]bstain
You have read & understood the proposal but don't care
about the outcome
The result of the vote will be used by the cleanup committee:
Y (if majority): we will include in a "block" resolution
N (if majority): we will not raise the issue at X3J13
I: if no "unconditional" majority, your conditions will
affect what we propose to X3j13
C: we will attempt to clarify (even if the issue gets
a majority vote.)
Our goal is that all "voters" understand all
the issues.
A: your vote will not count in the total
Who can vote?
Anyone who wants to vote may do so, whether members of X3J13, observers, or
interested parties. Please indicate on your ballot your organization,
whether your organization is an X3J13 member, and whether your ballot is
the "official" position of your organization.
Reminders:
The fact that a proposal is before you does not mean that the cleanup
committee, or the person(s) listed as the author(s), actually endorse the
proposal. Please read the discussion section if you would like
testimonials.
Several of the proposals are interlinked in important ways. The linkage is
identified in each proposal. Please be careful to not vote for mutually
exclusive proposals.
There are a large number of issues remaining; some already "ready for
release". The selection criteria was to bring to ballot those issues which
were already pending prior to the October 1988 issue. (A few "new" issues
slipped in....) No "slight" of other issues is intended. We will bring to
the January meeting drafts of many of the issues still pending.
Only those issues modified since the October distribution have been
e-mailed to the X3J13 distribution list. All of these issues are available
online for anonymous FTP from host arisia.xerox.com, directory
clcleanup/pending. (User name "anonymous", any password.)
Again, due to my haste in preparing this ballot, there have been several
mistakes and "hasty" issue releases, for which I apologize.
I will not be reading electronic mail until after 3 January, so please send
administrative mail or ballots to cl-cleanup@sail.stanford.edu.
If you wish to mail your ballot in hardcopy form, please
send it to:
Larry Masinter
Xerox Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, California 94022
USA
before January 7.
If you wish to discuss several unrelated issues, please send a separate
message for each issue, preferably with Subject of the form "Re: Issue:
ISSUE-NAME (Version nnnn)".
!
ARGUMENTS-UNDERSPECIFIED:SPECIFY
Version 4, 21-Sep-88, Mailed 4 Dec 88
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
Version 9, 31-Oct-88, Mailed 5 Dec 88
CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY
Version 5, 5-Dec-88, Mailed 5 Dec 88
CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE
Version 1, 14-Sep-88, Mailed 6 Oct 88
DECLARATION-SCOPE:NO-HOISTING
DECLARATION-SCOPE:LIMITED-HOISTING
Version 4, 15-Nov-88, Mailed 9-Dec-88
DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION
Version 4, 5-Dec-88, Mailed 5-Dec-88
DECLARE-TYPE-FREE:ALLOW
Version 8, 7-Dec-88, Mailed 9-Dec-88
DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE
Version 2, 30-Sep-88, Mailed 6 Oct 88
DEFPACKAGE:ADDITION
Version 7, 2-Nov-88, Mailed 5 Dec 88
DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
Version 2, 21-Sep-88, Mailed 6 Oct 88
DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
Version 3, 7 Dec 88, Mailed 12-Dec-88
DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR
Version 4, 31-Oct-88, Mailed 12-Dec-88
DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE
DESCRIBE-INTERACTIVE:NO
Version 4, 15-Nov-88 , Mailed 7-Dec-88
DOTTED-MACRO-FORMS:ALLOW
Version 3, 15-Nov-88, Mailed 7-Dec-88
EQUAL-STRUCTURE:STATUS-QUO
Version 5, 1-Oct-88, Mailed 8 Oct 88
EXIT-EXTENT:MINIMAL
EXIT-EXTENT:MEDIUM
Version 5, 12-Dec-88, Mailed 12-Dec-88
EXPT-RATIO:P.211
Version 3, 31-Oct-88, Mailed 7 Dec 88
FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION
FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM
Version 4, 7-Dec-88, Mailed 12-Dec-88
FORMAT-E-EXPONENT-SIGN:FORCE-SIGN
Version 2, 2 Oct 88, Mailed 6 Oct 88
FORMAT-PRETTY-PRINT:YES
Version 7, 15 Dec 88, Mailed 7 Dec 88
FUNCTION-COMPOSITION:NEW-FUNCTIONS
FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS
Version 4, 12 Dec 88, Mailed 12 Dec 88
FUNCTION-DEFINITION:FUNCTION-SOURCE
Version 2, 09-Dec-88 , Mailed 9 Dec 88
FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE
Version 3, 7-Dec-88, Mailed 12-Dec-88
FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE
Version 5, 14-Nov-88 , Mailed 8-Dec-88
GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD
Version 2, 8 Dec 88, Mailed 8 Dec 88
HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER
Version 7, 8-Dec-88, Mailed 9-Dec-88
HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS
Version 1, 11-Nov-88 , Mailed 12 Dec 88
HASH-TABLE-TESTS:ADD-EQUALP
Version 2, 8-Dec-88, Mailed 8 Dec 88
IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY
Version 4, 12-Dec-88, Mailed 12-Dec-88
LAMBDA-FORM:NEW-MACRO
Version 4, 22-Nov-88, Mailed 8-Dec-88
LCM-NO-ARGUMENTS:1
Version 1, 17 Oct 88, Mailed 8 Dec 88
LISP-SYMBOL-REDEFINITION:DISALLOW
Version 5, 22-Nov-88, Mailed 8 Dec 88
MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT
Version 2, 8 Oct 88, Mailed 12-Dec-88
MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
Version 2, 09-Jun-88, Mailed 8 Oct 88
NTH-VALUE:ADD
Version 4, 8-Dec-88, Mailed 8 Dec 88
PACKAGE-CLUTTER:REDUCE
Version 6, 12-Dec-88, Mailed 12-Dec-881
PACKAGE-DELETION:NEW-FUNCTION
Version 5, 21 nov 88, Mailed 8 Dec 88
PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN
Version 1 27-Jun-88, Mailed 7 Oct 88
PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR
Version 3, 8-Oct-88, Mailed 8 Oct 88
PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK
Version 3, 20 Sep 88, Mailed 8 Oct 88
PROCLAIM-LEXICAL:LG
Version 9, 8-Dec-88, Mailed 12-Dec-88
RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER
Version 3, 9-Oct-88, Mailed 14-Oct-88
RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL
Version 1, 14-Sep-88, Mailed 7 Oct 88
REQUIRE-PATHNAME-DEFAULTS:ELIMINATE
Version 6, 9 Dec 88, mailed 09 Dec 88
REST-LIST-ALLOCATION:NEWLY-ALLOCATED
REST-LIST-ALLOCATION:MAY-SHARE
REST-LIST-ALLOCATION:MUST-SHARE
Version 3, 12-Dec-88, mailed 12-Dec-88
RETURN-VALUES-UNSPECIFIED:SPECIFY
Version 6, 9 Dec 88 mailed 9-Dec-88
ROOM-DEFAULT-ARGUMENT:NEW-VALUE
Version 1 12-Sep-88 mailed 8 Oct 88
[The following are mutually exclusive]
SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
Version 3, 4-Nov-87, mailed Nov 87
SETF-PLACES:ADD-SETF-FUNCTIONS
Version 1, 11-Nov-88, mailed 9-Dec-88
SETF-SUB-METHODS:DELAYED-ACCESS-STORES
Version 5, 12-Feb-88 mailed 8 Oct 88
STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS
Version 8, 8 Jul 88, Mailed 7 Oct 88
STEP-ENVIRONMENT:CURRENT
Version 3, 20-Jun-88, mailed 7 Oct 88
STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
version 2, 30-Nov-88 mailed 9 Dec 88
(expect amendment T => "true")
STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS
Version 6, 30-Nov-88, mailed 9 dec 88
expect amendment:
LINE-WIDTH ==> STREAM-LINE-WIDTH
LINE-POSITION ==> STREAM-LINE-POSITION
PRINTED-WIDTH ==> STREAM-STRING-WIDTH
SUBTYPEP-TOO-VAGUE:CLARIFY
Version 4, 7-Oct-88, mailed 7 Oct 88
SYMBOL-MACROLET-DECLARE:ALLOW
Version 2, 9-Dec-88, mailed 9 Dec 88
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM
Version 5, 30-Nov-88, mailed 9 Dec 88
TAGBODY-CONTENTS:FORBID-EXTENSION
Version 5, 9-Dec-88 mailed 9 Dec 88
TAILP-NIL:T
Version 5, 9-Dec-88, mailed 12-Dec-88
TEST-NOT-IF-NOT:FLUSH-ALL
TEST-NOT-IF-NOT:FLUSH-TEST-NOT
Version 3, 1 Dec 88 mailed 9 dec
TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS
Version 3, 12-Dec-88, mailed 12 Dec 88
(some "bugs" in the proposal)
UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW
Version 2, 2-Dec-88, mailed 12-Dec-88
VARIABLE-LIST-ASYMMETRY:SYMMETRIZE
Version 3, 08-Oct-88, mailed 9 Dec 88
∂13-Dec-88 0800 X3J13-mailer CommonLisp/C interface
Received: from goldhill.com ([128.168.1.225]) by SAIL.Stanford.EDU with TCP; 13 Dec 88 07:58:08 PST
Received: by god.goldhill.com; Tue, 13 Dec 88 10:57:48 EST
Date: Tue, 13 Dec 88 10:57:48 EST
From: ejs@goldhill.com (Eric Swenson)
Message-Id: <8812131557.AA14746@goldhill.com>
To: x3j13@sail.stanford.edu
Cc: kahle@think.com
In-Reply-To: kahle@think.com's message of Mon, 12 Dec 88 20:32:57 EST <8812130132.AA13377@ungar.think.com>
Subject: CommonLisp/C interface
We at Gold Hill agree with Brewster's assessment that the lack of
standards vis-a-vis a foreign-function interface are a serious
deficiency for Common Lisp system programmers. Although the Lucid 3.0
foreign function interface may be lacking in some respects, it is
certainly a good starting place. I second the motion to adopt Lucid's
interface as a standard -- or at least the starting point for a standard.
-- Eric Swenson
Gold Hill Computers, Inc.
∂13-Dec-88 0819 X3J13-mailer CommonLisp/C interface
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Dec 88 08:19:22 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 13 Dec 88 10:29:30 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 13 Dec 88 11:14:54 EST
Date: Tue, 13 Dec 88 11:15 EST
From: Barry Margolin <barmar@Think.COM>
Subject: CommonLisp/C interface
To: kahle@Think.COM
Cc: x3j13@sail.stanford.edu
In-Reply-To: <8812130132.AA13377@ungar.think.com>
Message-Id: <19881213161509.5.BARMAR@OCCAM.THINK.COM>
Date: Mon, 12 Dec 88 20:32:57 EST
From: kahle@Think.COM
We at Thinking Machines have been using Common Lisp as a system programming
language. The principle features that are missing from CommonLisp for this
purpose is the Lisp/C interface specification. This deficiency makes our
code non-portable.
It's a bit late in the process for us to consider an entirely new area
of standardization. We are hoping to get a draft standard out in the
next six months or so. We chartered ourselves with producing a standard
based primarily on CLtL, with the addition of necessary cleanups, an
object-oriented programming facility, error handling, and improved
iteration facilities, and we formed subcommittees to work on each area.
Had we planned on including foreign function calling at that time we
could have formed such a subcommittee, and I am confident that we would
have had something acceptable by this time. But at this time we are
basically finalizing our work, and I think it is not the time to start
discussing a new, potentially controversial aspect of the language.
On the other hand, Lucid has provided a good set of
functions that have gotten better in each release. To start the
discussion:
I propose the Common Lisp committee adopt the Lucid 3.0 foreign function
interface as the Common Lisp standard.
On what do you base this particular recommendation? Yes, Lucid has a
good set of foreign function interfaces, but so do most other vendors.
There was a good article in Lisp Pointers I.5: "Foreign Functions and
Common Lisp", by Harlan Sexton of Lucid. In addition to describing the
existing foreign function interfaces of several Lisps (Franz ExCL, Lucid
CL, and DEC Vax Lisp), he also includes suggestions on what should be in
a standard interface. Since the developer responsible for Lucid's FFI
doesn't feel that it is appropriate for standardization, why do you?
barmar
∂13-Dec-88 0833 X3J13-mailer Re: CommonLisp/C interface
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 13 Dec 88 08:32:56 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA01286; Tue, 13 Dec 88 08:34:57 PST
Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA17218; Tue, 13 Dec 88 08:31:37 PST
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
id AA02234; Tue, 13 Dec 88 08:32:11 PST
Message-Id: <8812131632.AA02234@suntana.sun.com>
To: ejs@goldhill.com (Eric Swenson)
Cc: x3j13@sail.stanford.edu, kahle@think.com
Subject: Re: CommonLisp/C interface
In-Reply-To: Your message of Tue, 13 Dec 88 10:57:48 -0500.
<8812131557.AA14746@goldhill.com>
Date: Tue, 13 Dec 88 08:32:07 PST
From: kempf@Sun.COM
Perhaps we can schedule a discussion and vote at the Hawaii meeting?
jak
∂13-Dec-88 0910 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Call for Papers
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Dec 88 09:10:43 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA26335; Tue, 13 Dec 88 09:10:19 PDT
Message-Id: <8812131710.AA26335@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 13 Dec 88 09:10:51 PST
Received: by BYUADMIN (Mailer R2.01) id 3432; Tue, 13 Dec 88 10:08:14 MST
Date: Tue, 13 Dec 88 09:54:25 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
mitchell%community-chest.mitre.org@GATEWAY.MITRE.ORG
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: mitchell%community-chest.mitre.org@GATEWAY.MITRE.ORG
Subject: Call for Papers
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
-------------------------------------------------------------------------
***** CALL FOR PAPERS AND PARTICIPATION *****
28th Annual Technical Symposium of the Washington, D.C. Chapter of the ACM
INTERFACES: Systems and People Working Together
National Institute of Standards and Technology
Gaithersburg, Maryland - August 24, 1989
No computer is an island. Increasingly, systems are being tied together
to improve their value to the organizations they serve. This symposium will
explore the theoretical and practical issues in interfacing systems and in
enabling people to use them effectively.
*** SOME TOPICS OF INTEREST FOR SUBMITTED PAPERS ***
* HUMAN FACTORS *
User interfaces Meeting the needs of handicapped users
Conquering complexity Designing systems for people
Intelligent assistants The human dimension of information interchange
* SYSTEMS INTEGRATION *
Communications networks Distributed databases
Data standardization System fault tolerance
Communications standards (e.g. GOSIP)
* STRATEGIC SYSTEMS *
Decision support systems Embedding expert systems in information systems
Strategic info systems Computer Aided Logistics Support (CALS)
* SYSTEM DEVELOPMENT AND OPERATION *
Quality control and testing Designing a system of systems
System management Conversion and implementation strategies
Software tools and CASE Identifying requirements thru prototyping
* ENABLING TECHNOLOGIES FOR APPLICATIONS PORTABILITY *
Ada Database management
Open software Open protocol technology
Operating systems (e.g., POSIX)
==> DON'T BE LIMITED BY OUR SUGGESTIONS - MAKE YOUR OWN!
Both experienced and first-time authors are encouraged to present their
work. Papers will be refereed. A length of 10 to 20 double-spaced pages is
suggested.
Those presenting a paper are entitled to register for the symposium at
the early advance registration rate.
To propose special sessions or noncommercial demonstrations, please send
three copies of an extended abstract to the Program Chairman at the address
below.
Note: A paper must include the name, mailing address, and telephone
number of each author or other presenter. Authors of accepted papers must
transfer copyright to ACM for material published in the Proceedings (excepting
papers that cannot be copyrighted under Government regulations).
The ACM policy on prior publication was revised in 1987. A complete
statement of the policy appears in the November 1987 issue of Communications
of the ACM. In part it states that "republication of a paper, possibly
revised, that has been disseminated via a proceedings or newsletter is
permitted if the editor of the journal to which it has been submitted judges
that there is significant additional benefit to be gained from republication."
*** SCHEDULE ***
March 2, 1989 Please send five copies of your paper to the Program Chairman:
Dr. Milton S. Hess
American Management Systems, Inc.
1525 Wilson Boulevard
Arlington, VA 22209
April 13, 1989 Acceptance notification
June 22, 1989 Final camera ready papers are due
August 24, 1989 Presentation at the symposium
If you have any questions or suggestions, please contact:
Symposium General Chairman: Charles E. Youman, The MITRE Corporation,
(703) 883-6349 (voice), (703) 883-6308 (FAX), or youman@mitre.org (internet).
Program Chairman: Dr. Milton Hess, American Management Systems, Inc.,
(703) 841-5942 (voice) or (703) 841-7045 (FAX).
NIST Liaison: Ms. Elizabeth Lennon, National Institute of Standards and
Technology (formerly the National Bureau of Standards), (301) 975-2832 (voice)
or (301) 948-1784 (FAX).
∂13-Dec-88 1115 X3J13-mailer [barmar@Think.COM: CommonLisp/C interface]
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 13 Dec 88 11:15:39 PST
Received: from kent-state ([192.9.200.24]) by heavens-gate.lucid.com id AA05058g; Tue, 13 Dec 88 11:12:46 PST
Received: by kent-state id AA01166g; Tue, 13 Dec 88 11:10:11 PST
Date: Tue, 13 Dec 88 11:10:11 PST
From: Harlan Sexton <hbs@lucid.com>
Message-Id: <8812131910.AA01166@kent-state>
To: kahle@Think.COM, barmar@Think.COM, ejs@goldhill.com
Cc: x3j13@sail.stanford.edu
In-Reply-To: Eric Benson's message of Tue, 13 Dec 88 10:00:56 pst <8812131800.AA00280@blacksox>
Subject: [barmar@Think.COM: CommonLisp/C interface]
I am very pleased to hear people pushing for a Common Lisp standard for a
foreign-function interface, and I am especially pleased that they like what
we did at Lucid enough to recommend it as a starting point. As Barry
Margolin mentioned in his mail, I wrote a survey/proposal for CL FFI's
which appeared in Lisp Pointers, and also in Computer Language, Aug. 1988.
(We can send hard-copies or a LaTeX "source" of this article to interested
parties.)
To summarize my views, I like Lucid's FFI best (not too surprising), but
each of the FFI's that I looked at (Franz ExCL, DEC Vax Lisp, Lucid CL)
have features that I feel belong in the standard and that are found in none
of the other FFI's. (KCL has, I think, the best Lisp to C interface of all,
but duplicating that in any other Lisp just doesn't seem feasible.)
Ideally we would have implemented my proposed standard FFI, but it was only
after implementing the one we did and using it that some of its
short-comings were seen. I then looked (again) at what had been done with
some other implementations, thought for awhile, and formulated a proposal
which seemed to add the features missing from what we had done (and to fix
some design warts).
I would be very interested in reactions to my proposal, because it
currently exists only on paper is still very easy to change. I expect that
we will eventually implement this proposal (although it is not scheduled or
even seriously planned at this time), and it would be nice to have some
outside reactions temper the design.
--Harlan
∂13-Dec-88 1120 X3J13-mailer CommonLisp/C interface
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Dec 88 11:20:12 PST
Received: from fafnir.think.com by Think.COM; Tue, 13 Dec 88 13:31:56 EST
Return-Path: <kahle@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 13 Dec 88 14:18:22 EST
Received: from ungar.think.com by verdi.think.com; Tue, 13 Dec 88 14:16:55 EST
Received: by ungar.think.com; Tue, 13 Dec 88 14:18:18 EST
Date: Tue, 13 Dec 88 14:18:18 EST
From: kahle@Think.COM
Message-Id: <8812131918.AA15056@ungar.think.com>
To: barmar@Think.COM
Cc: x3j13@sail.stanford.edu
In-Reply-To: Barry Margolin's message of Tue, 13 Dec 88 11:15 EST <19881213161509.5.BARMAR@OCCAM.THINK.COM>
Subject: CommonLisp/C interface
Date: Tue, 13 Dec 88 11:15 EST
From: Barry Margolin <barmar@Think.COM>
Date: Mon, 12 Dec 88 20:32:57 EST
From: kahle@Think.COM
We at Thinking Machines have been using Common Lisp as a system programming
language. The principle features that are missing from CommonLisp for this
purpose is the Lisp/C interface specification. This deficiency makes our
code non-portable.
It's a bit late in the process for us to consider an entirely new area
of standardization.
...
This is a reasonable reply, of course. I have not followed your committee,
so I am sending this out of the blue.
The reason I bring it up is that the foreign function interface (to C) has
become very important to us. Without a standard we will have a very
difficult time porting much of our software if we ever want to (and we have
no plans to port as far as I know).
On the other hand, Lucid has provided a good set of
functions that have gotten better in each release. To start the
discussion:
I propose the Common Lisp committee adopt the Lucid 3.0 foreign function
interface as the Common Lisp standard.
On what do you base this particular recommendation? Yes, Lucid has a
good set of foreign function interfaces, but so do most other vendors.
There was a good article in Lisp Pointers I.5: "Foreign Functions and
Common Lisp", by Harlan Sexton of Lucid. In addition to describing the
existing foreign function interfaces of several Lisps (Franz ExCL, Lucid
CL, and DEC Vax Lisp), he also includes suggestions on what should be in
a standard interface. Since the developer responsible for Lucid's FFI
doesn't feel that it is appropriate for standardization, why do you?
barmar
I suggested Lucid's interface to get the conversation rolling and no more.
I have not studied the other vendor's interfaces, but the lucid interface
is pretty good. I thought that making a specific recommendation would draw
out counter proposals.
-brewster
brewster@think.com
∂13-Dec-88 1233 X3J13-mailer Re: CommonLisp/C interface
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 13 Dec 88 12:33:39 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
id AA07900; Tue, 13 Dec 88 15:28:14 EST
Received: from localhost by mist. (4.0/SMI-4.0)
id AA11784; Tue, 13 Dec 88 14:24:15 EST
Message-Id: <8812131924.AA11784@mist.>
To: Barry Margolin <barmar@Think.COM>
Cc: x3j13@sail.stanford.edu, kahle@think.com
Subject: Re: CommonLisp/C interface
In-Reply-To: Your message of Tue, 13 Dec 88 11:15:00 -0500.
<19881213161509.5.BARMAR@OCCAM.THINK.COM>
Date: Tue, 13 Dec 88 14:24:13 EST
From: Dan L. Pierson <pierson@mist.encore.com>
On what do you base this particular recommendation? Yes, Lucid has a
good set of foreign function interfaces, but so do most other vendors.
There was a good article in Lisp Pointers I.5: "Foreign Functions and
Common Lisp", by Harlan Sexton of Lucid. In addition to describing the
existing foreign function interfaces of several Lisps (Franz ExCL, Lucid
CL, and DEC Vax Lisp), he also includes suggestions on what should be in
a standard interface. Since the developer responsible for Lucid's FFI
doesn't feel that it is appropriate for standardization, why do you?
Well, actually Lucid rewrote their foreign function interface to
essentially what's in Harlan's paper for 3.0. So it would seem likely
that the responsible developer does support it.
I agree that it's late in the standardization process to entertain
major new areas. On the other hand, as Larry Masinter pointed out at
the last meeting, the foreign function interface is one of the three
most important remaining areas to standardize. By now, all stock
hardware vendors have significant experience in this area; at least
one vendor has moved to a second generation design (presumably after
discovering shortcomings in their first generation design).
Therefore, we do have a substantial body of current practice and
experience to draw on.
I think it would be well worthwhile to work some on this area and see
if there really is fundamental disagreement before assuming that we
can't succeed in time.
∂13-Dec-88 1442 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu cs300
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Dec 88 14:42:08 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 13 Dec 88 14:39:25-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA12791; Tue, 13 Dec 88 14:38:33 PDT
Date: Tue, 13 Dec 88 14:38:33 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8812132238.AA12791@Tenaya.stanford.edu>
To: faculty@score
Subject: cs300
I have received sufficient positive responses about running cs300
during Winter Quarter to conclude that we ought to do it. Any
volunteers? The main tasks are to schedule speakers, to introduce the
speakers, and to preside over discussion (which the students would
like to see more of). This quarter, the seminar has occurred on
Thursdays from 4:15-5:30. -Nils
∂13-Dec-88 1649 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Calgary theory positions
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Dec 88 16:49:32 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA26016; Tue, 13 Dec 88 16:48:46 PDT
Message-Id: <8812140048.AA26016@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 13 Dec 88 16:49:05 PST
Received: by BYUADMIN (Mailer R2.01) id 3854; Tue, 13 Dec 88 17:45:16 MST
Date: Tue, 13 Dec 88 18:31:15 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
lisa higham <higham%CS.UBC.CA@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMT
From: lisa higham <higham%CS.UBC.CA@Forsythe.Stanford.EDU>
Subject: Calgary theory positions
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
-------------------------------------------------------------------------
Theory Positions at the University of Calgary
The profile of the department of Computer Science at the
University of Calgary has been steadily strengthening due to
significant contributions in many areas of applied computer
science. The department recognizes that strong underpinnings in
theoretical computer science are essential for continued
development. Therefore, the university is committed to building
a larger and stronger theoretical group to complement the well
established applied component of the department. The computer
science department currently has open two tenure track positions
at the level of assistant professor. It expects to fill both
positions with strong candidates capable of maintaining active
and significant research in core areas of theoretical computer
science.
The department encourages and supports inter-departmental and
inter-university collaboration. For example, successful
candidates will enjoy close association with the department of
computer science at the University of British Columbia where
there is an outstanding group of theoretical computer
scientists. The activities of the newly formed theory seminar
WOBCATS (Wash., Oregon, B.C., Alberta --- comparable to BATS in
California) are enthusiastically supported by the department.
The research interests of several members of the math department
at the University of Calgary intersect with subdomains in
theoretical computer science.
The department currently has 25 full time faculty members. It
has active graduate programmes at both the Ph.D. and M.Sc.
levels. Restricted enrollment applies in the undergraduate
programme.
The University of Calgary in Southern Alberta is a modern campus
with excellent facilities including those that are the legacy of
the 1988 Olympics. Banff, Kananaskis and Jasper Parks (all
easily and quickly accessible from Calgary) are among the worlds
most scenic areas and offer unlimited opportunities for outdoor
recreation.
Interested strong candidates should direct applications to:
Dr. John Kendall, chairman
Department of Computer Science
The University of Calgary
2500 University Drive N.W.
Calgary, Alberta, Canada T2N 1N4
telephone: (403) 220--6015
I have recently accepted a position in the computer science
department at the University of Calgary and am excited by the
prospect of participating in the growth of a vibrant theory
group. I would be happy to supply further information. I can
be reached at the University of British Columbia until
mid-December:
Lisa Higham
telephone: (604) 228--4907
e-mail: higham@cs.ubc.ca
and after January 3 at the University of Calgary:
telephone: (403) 220--6015
e-mail: higham@calgary.ca
∂13-Dec-88 1719 betsy@russell.Stanford.EDU Schedule for 1988-89
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Dec 88 17:19:43 PST
Received: by russell.Stanford.EDU (4.0/4.7); Tue, 13 Dec 88 17:21:32 PST
Date: Tue 13 Dec 88 17:21:31-PST
From: Betsy Macken <BETSY@CSLI.Stanford.EDU>
Subject: Schedule for 1988-89
To: evesem@russell.Stanford.EDU
Message-Id: <598065691.0.BETSY@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
Here's our 1988-89 schedule:
Evening Seminar Schedule
1988-89
November 16 Dave Rumelhart
December 7 Ivan Sag
January 11 Jon Barwise
January 25 John McCarthy
February 8 Herb Clark
February 22 Stanley Peters
March 8 Ellen Markman
March 22 Amos Tversky
April 12 Eve Clark
April 26 Nils Nilsson
May 10 John Etchemendy
May 24 Yoav Shoham
-------
∂14-Dec-88 1043 X3J13-mailer Re: [barmar@Think.COM: CommonLisp/C interface]
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 14 Dec 88 10:43:16 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
id AA00847; Wed, 14 Dec 88 13:42:09 EST
Received: from localhost by mist. (4.0/SMI-4.0)
id AA00470; Wed, 14 Dec 88 13:42:04 EST
Message-Id: <8812141842.AA00470@mist.>
To: Harlan Sexton <hbs@lucid.com>
Cc: x3j13@sail.stanford.edu
Subject: Re: [barmar@Think.COM: CommonLisp/C interface]
In-Reply-To: Your message of Tue, 13 Dec 88 11:10:11 -0800.
<8812131910.AA01166@kent-state>
Date: Wed, 14 Dec 88 13:42:02 EST
From: Dan L. Pierson <pierson@mist.encore.com>
I was confused, sorry. Of course your Lisp Pointers paper is
different from the Lucid 3.0 implementation. Your paper also looks
like an improvement, though it is missing a few important features
such as the ability to determine the size of a foreign structure.
We should establish a working group on foreign function interface at
the January meeting. Will you be able to be there?
We should also find a way to move this discussion to another mailing
listt, but I'm afraid that that may be tied up in question of moving
everything off of Sail...
∂14-Dec-88 1157 X3J13-mailer Issue: PACKAGE-CLUTTER (Version 6)
Received: from goldhill.com ([128.168.1.211]) by SAIL.Stanford.EDU with TCP; 14 Dec 88 11:56:23 PST
Received: by goldhill.com; Wed, 14 Dec 88 14:55:55 EST
Date: Wed, 14 Dec 88 14:55:55 EST
From: rpk@goldhill.com (Robert Krajewski)
Message-Id: <8812141955.AA16807@goldhill.com>
To: cl-cleanup@sail.stanford.edu
Cc: x3j13@sail.stanford.edu, masinter.pa@xerox.com
In-Reply-To: cl-cleanup@sail.stanford.edu's message of 12 Dec 88 13:44 PST <881212-134536-5049@Xerox>
Subject: Issue: PACKAGE-CLUTTER (Version 6)
I just noticed two problems in this paragraph:
A valid implimentation may have or put additional properties
on symbols (even user created symbols) as long as the
property indicators are not in the LISP, KEYWORD or USER
package.
1. The spelling of the third word.
2. It should be OK for an implementation to use property list indicators
that are *internal* symbols in the LISP package. (Of course, the ``internal''
concept doesn't make sense, really, for keywords, and internal USER symbols
are the most common kind.)
∂14-Dec-88 1205 X3J13-mailer Re: [barmar@Think.COM: CommonLisp/C interface]
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 14 Dec 88 12:05:31 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA03961; Wed, 14 Dec 88 12:07:13 PST
Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA04016; Wed, 14 Dec 88 12:03:50 PST
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
id AA04870; Wed, 14 Dec 88 11:24:33 PST
Message-Id: <8812141924.AA04870@suntana.sun.com>
To: Dan L. Pierson <pierson@mist.encore.com>
Cc: Harlan Sexton <hbs@lucid.com>, x3j13@sail.stanford.edu
Subject: Re: [barmar@Think.COM: CommonLisp/C interface]
In-Reply-To: Your message of Wed, 14 Dec 88 13:42:02 -0500.
<8812141842.AA00470@mist.>
Date: Wed, 14 Dec 88 11:24:09 PST
From: kempf@Sun.COM
>We should establish a working group on foreign function interface at
>the January meeting.
This sounds like an excellent idea.
jak
∂14-Dec-88 1659 X3J13-mailer Hawaii registration
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 14 Dec 88 16:59:14 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA11077g; Wed, 14 Dec 88 16:56:28 PST
Received: by challenger id AA13417g; Wed, 14 Dec 88 16:52:36 PST
Date: Wed, 14 Dec 88 16:52:36 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8812150052.AA13417@challenger>
To: x3j13@sail.stanford.edu
Subject: Hawaii registration
Please let me know if there are any changes/additions. Note that there will
be room to bring guests to the luau, I just need to know how many.
---jan---
X3J13 Attendee Information
12/14/88
Name Institute Paid L1 L2 L3 Luau
Jim Antonisse MITRE Corp. 113.50 y y y 1
Bill Arbaugh U.S. Army -0- y y y -
Paul Beiser HP -0- y y y -
Jerome Chailloix ILOG -0- y y y -
Kathy Chapman DEC -0- y y y 1
Jeff Dalton University of Edinburgh -0- y y y -
Jerry Duggen HP -0- y y y -
Patrick Dussud Lucid, Inc. -0- y y y 1
Dick Gabriel Lucid, Inc. -0- y y y 1
Kevin Layer Franz, Inc. $75.00 y y y 1
Thom Linden IBM $75.00 y y y 1
David Loeffler MCC 113.50 y y y 1
Larry Masinter Xerox $75.00 y y y 1
Greg Nuyens ILOG -0- y y y -
Chris Perdue SUN MicroSystems -0- y y y 1
Jeff Rosenking Grumman Corp. -0- y y y -
David Unietis Lucid, Inc. -0- y y y 1
Mary Van Deusen IBM -0- y y y -
Ellen Waldrum TI $75.00 y y y 2
JonL White Lucid, Inc. -0- y y y 1
Jan Zubkoff Lucid, Inc. -0- y y y 2
∂14-Dec-88 1707 X3J13-mailer Re: CommonLisp/C interface
Received: from FRED.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 14 Dec 88 17:06:25 PST
Received: from FRED.SLISP.CS.CMU.EDU by FRED.SLISP.CS.CMU.EDU; 14 Dec 88 20:03:13 EST
To: Dan L. Pierson <pierson@mist.encore.com>
cc: Barry Margolin <barmar@Think.COM>, x3j13@sail.stanford.edu,
kahle@think.com
Subject: Re: CommonLisp/C interface
In-reply-to: Your message of Tue, 13 Dec 88 14:24:13 -0500.
<8812131924.AA11784@mist.>
Date: Wed, 14 Dec 88 20:00:32 EST
From: Rob.MacLachlan@WB1.CS.CMU.EDU
I agree that a foreign function call mechanism is an important part of any
Common Lisp implementation on an architecture that supports multiple
languages. Nonetheless, I think that attempts to standardize foreign
function call are premature. Good results are especially unlikely under
time pressure.
I believe that the acid test of a foreign interface facility is that it
can be use to define an interface to arbitrary foreign subroutine library.
Use of magical glue code that knows about Lisp or foreign data structure
representations isn't allowed.
Inter-language communication is in general a hard problem. The problem
isn't in calling a routine written in another language, it is with making
foreign data structures sensible. Consider complex data structures: linked
list structures, pointers to arrays of records, etc. Also consider byte
ordering, foreign compiler decisions about record packing, etc.
Since there are spurious proposals in the air, I propose that the CMU
Common Lisp Alien type, the associated C type definition macros, and the
DEFROUTINE macro be made part of Common Lisp. The CMU Lisp facility comes
a lot closer to meeting the desiderata than any other foreign interface
facility that I have seen. For example, we provided a complete interface
to version 10 Xlib without using any glue code.
This is a spurious proposal, since I am sure that our current facility can
be improved quite a bit. It was also never designed to be part of a
portable standard.
In addition to the technical issue of "do we know a good foreign interface
when we see one?", there is the language definition issue of "do we know
how to define a foreign interface mechanism in the Common Lisp context, and
does it make any sense to do so?"
The current standardization effort is undertaking to determine what it
means to "be Common Lisp": what properties all Common Lisp implementations
must have. Availability of C or any other foreign language is not a
required part of the Common Lisp environment, so it doesn't make any sense
to adopt a foreign interface mechanism as part of the core Common Lisp
standard.
People interested in standardizing interface to C should look to what was
done with CLX (the Common Lisp interface to X11.) Informal work on a
mailing list resulted in a Common Lisp extension that is available in
almost all environments where it is meaningful.
Rob
∂15-Dec-88 0802 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Call for Papers/Distributed Comp Workshop South of France
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Dec 88 08:01:59 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA15390; Thu, 15 Dec 88 08:01:39 PDT
Message-Id: <8812151601.AA15390@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Thu, 15 Dec 88 08:02:10 PST
Received: by BYUADMIN (Mailer R2.01) id 2515; Thu, 15 Dec 88 08:59:07 MST
Date: Thu, 15 Dec 88 09:45:50 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Paul Vitanyi <paulv%CWI.NL@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Paul Vitanyi <paulv%CWI.NL@Forsythe.Stanford.EDU>
Subject: Call for Papers/Distributed Comp Workshop South of France
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
-------------------------------------------------------------------------
3rd INTERNATIONAL WORWSHOP
ON
DISTRIBUTED ALGORITHMS
Nice, September 26-28, 1989
Following the two first successful Workshops on Distributed Algo-
rithms in Ottawa (1985) and Amsterdam (1987), the third workshop
of this kind will be held at La Colle sur Loup, near Nice,
France. The workshop is intended to provide a forum for research-
ers and other parties interested in distributed algorithms on
communication networks, graphs and decentralized systems. Aim is
to present recent research results, explore directions for future
research, and identify common fundamental techniques that serve
as building blocks in many distributed algorithms.
Paper are solicited describing original results in all areas of
distributed algorithms and their applications, including e.g.
- distributed combinatorial algorithms
- distributed optimization algorithms
- distributed graphs algorithms
- routing algorithms
- distributed algorithms for control and communication
- design of network protocols
- distributed database techniques
- algorithms for transaction management
- distributed algorithms for decentralizated systems
- composition of distributed algorithms
- fail-safe and fault-tolerant distributed algorithms
Intended contributors are invited to submit 8 copies of a full
paper (not exceeding 12 pages) to one of the scientific chairmen.
Jean-Claude Bermond Michel Raynal
LRI, Bat 490 IRISA
Universite Paris-Sud Campus de Beaulieu
91405 Orsay, France 35042 Rennes, France
e-mail bermond@FRLRI61.BITNET e-mail raynal@irisa.fr (uucp)
or bermond@lri.lri.fr (uucp)
Submissions must arrive before April 25, 1989. Authors will be
notified of acceptance or rejection by June 19, 1989. Proceedings
will be published, possibly in the Springer Verlag series Lecture
Notes in Computer Science. The final version of accepted
papers must arrive in camera-ready form before July 15, 1989, to
ensure the availability of the proceedings at the conference.
PROGRAM COMMITEE
J-C Bermond (CNRS, LRI Ordsay, France)
F. Mattern (U. Kaiserslautern, Germany)
M. Raynal (IRISA, Rennes, France)
N. Santoro (Carlton University, Ottawa, Canada)
A. Segfall (Technion, Haifa, Israel)
S. Toueg (Cornell University, Ithaca, USA)
P. Vitanyi (C.W.I. and Univ. of Amsterdam, Netherlands)
Organizing chairman :
C. Lavault
INRIA
Domaine de Voluceau, Rocquencourt,
BP 105, 78153 Le Chesnay, France
General Information:
The workshop will be held at a French Holyday Center VVF, Chemin
de Montmeuille, 06480, La Colle sur Loup, France. This small
"provencal village" is located in a pine forest near Saint-Paul
de Vence, at 12 km from Nice Airport, 20 km from Cannes and 6 km
from the mediteranean sea. Further details will be mailed with
the second announcement. For further information contact either
J-C Bermond, C. Lavault, M. Raynal, or any member of the program
committee.
Please fill up this form and send it to ******* (will be pre-
cised)
NAME:
ADDRESS;
e-mail adress (if available ):
I Intend to submit a paper: yes no maybe
I want to receive the second announcement: yes no
∂15-Dec-88 0929 X3J13-mailer Re: [barmar@Think.COM: CommonLisp/C interface]
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 15 Dec 88 09:28:42 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa05577; 15 Dec 88 16:27 GMT
Date: Thu, 15 Dec 88 16:38:16 GMT
Message-Id: <6378.8812151638@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: [barmar@Think.COM: CommonLisp/C interface]
To: kempf@sun.com, "Dan L. Pierson" <pierson%mist.encore.com@NSS.Cs.Ucl.AC.UK>
In-Reply-To: kempf@com.sun's message of Wed, 14 Dec 88 11:24:09 PST
Cc: Harlan Sexton <@sail.stanford.edu:hbs@lucid.com>, x3j13@sail.stanford.edu
>We should establish a working group on foreign function interface at
>the January meeting.
I too think this is a good idea.
It also turns out that the ISO Lisp working group, WG-16, is supposed
to comment on a document, "Working documents on CALLING MECHANISMS
and LANGUAGE-INDEPENDENT DATA TYPES", prepared by WG-11, the working
group for Language Bindings.
Anyone interested in these issues may want to comment, and the plan,
at the last WG-16 meeting, was for anyone interested to prepare
comments by the next WG-16 meeting, in March.
Jeff Dalton, JANET: J.Dalton@uk.ac.ed
AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
∂15-Dec-88 0945 X3J13-mailer Re: [barmar@Think.COM: CommonLisp/C interface]
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 15 Dec 88 09:44:51 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA12664; Thu, 15 Dec 88 09:44:56 PST
Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA01149; Thu, 15 Dec 88 09:41:36 PST
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
id AA07434; Thu, 15 Dec 88 09:42:10 PST
Message-Id: <8812151742.AA07434@suntana.sun.com>
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Cc: kempf@Sun.COM, "Dan L. Pierson" <pierson%mist.encore.com@NSS.Cs.Ucl.AC.UK>,
Harlan Sexton <@sail.stanford.edu:hbs@lucid.com>,
x3j13@sail.stanford.edu
Subject: Re: [barmar@Think.COM: CommonLisp/C interface]
In-Reply-To: Your message of Thu, 15 Dec 88 16:38:16 +0000.
<6378.8812151638@subnode.aiai.ed.ac.uk>
Date: Thu, 15 Dec 88 09:42:08 PST
From: kempf@Sun.COM
Jeff:
Could you bring along a copy of this document to the Hawaii
meeting, presuming you're coming. If not, perhaps you could let
us know where we could get it, or mail it electronically or otherwise?
Thanx.
I'll ask Jan Zubkov about arranging a subcommittee meeting.
jak
∂15-Dec-88 1424 @Score.Stanford.EDU:jps@amadeus.Stanford.EDU panel on federal science funding
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Dec 88 14:24:02 PST
Received: from amadeus.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 15 Dec 88 14:20:59-PST
Received: by amadeus.Stanford.EDU (5.59/inc-1.0)
id AA07320; Thu, 15 Dec 88 14:21:03 PDT
Date: Thu, 15 Dec 88 14:21:03 PDT
From: jps@amadeus.Stanford.EDU (Jaswinder Singh)
Message-Id: <8812152221.AA07320@amadeus.Stanford.EDU>
To: ee-faculty@sierra.stanford.edu, faculty@score.stanford.edu
Subject: panel on federal science funding
The following is an announcement I received from Barbara Simons
at IBM Almaden:
>From: "Barbara B. Simons" <simons@IBM.com>
To: jps@amadeus.Stanford.EDU (Jaswinder Singh)
Cc: simons@ibm.com
Message-Id: <881215.105249.simons@IBM.com>
Subject: Re: report draft
In-Reply-To: Your message of Wed, 14 Dec 88 12:00:54 PDT
Status: RO
==============================
There will be a panel on federal funding of those sciences for which the DoD
(as opposed to the NIH) is the primary mission oriented funding agency. This
panel is to be held during the annual meeting of the AAAS and is jointly
sponsored by the American Association for the Advancement of Science, the
American Physical Society, and the American Association of Physics Teachers.
Date: Jan. 17, 1989
Place: the California Room of the St. Francis Hotel, San Francisco
Time: 8:30 A.M.
Federal Funding of the Academic Physical Sciences
Federal funding of science is a major component of science policy. Which
areas are funded, how much funding they receive, which agencies do the
funding, and who makes the decisions are important issues. Fields prosper and
decline according to these decisions. Graduate students' choice of specialty
is influenced by funding. Teaching loads and even tenure decisions can be
affected. Since funding has a profound influence on technology, funding
policy has significant economic repercussions. It also has political
repercussions, as politicians become increasingly involved with the funding
process. Scientific and academic freedom are at issue. Researchers who fear
that their funding may be cut for political reasons, even if the fears are
unfounded, may engage in self-censorship.
What impact has science funding policy had on universities?
What has been the effect of the increased emphasis on 'big science' in recent
years?
Is there an imbalance of funding sources for some scientific disciplines, and,
if so, is this a problem?
Have government policies with respect to science funding been in the best
interest of science?
Are there ways in which these policies can be improved?
How have the trends toward mission oriented and defense oriented funding
affected the quality and nature of scientific research?
Panelists
Prof. Philip Anderson (Nobel Prize)
Physics, Princeton University
Prof. Peter Lax (Wolf Prize)
Mathematics, Courant Institute
Dr. Robert Park
Executive Director, Office of Public Affairs, The American Physical Society
Dr. Burton Richter (Nobel Prize)
Director, SLAC
Dr. Robert M. Rosenzweig
President, Association of American Universities
Prof. William Thurston (Fields Medal)
Mathematics, Princeton University
Moderator: Dr. Barbara Simons
Computer Science, IBM Almaden Research Center
∂15-Dec-88 1504 X3J13-mailer Hawaii registration form
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 15 Dec 88 15:04:29 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00573g; Thu, 15 Dec 88 15:01:40 PST
Received: by challenger id AA14949g; Thu, 15 Dec 88 14:56:18 PST
Date: Thu, 15 Dec 88 14:56:18 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8812152256.AA14949@challenger>
To: x3j13@sail.stanford.edu
Subject: Hawaii registration form
It's been a while since I've sent this....
X3J13/ISO Meeting
X3J13: 1/16/89 - 1/18/89
ISO: 1/19/89 - 1/20/89
Kauai, Hawaii
Committee Meeting:
Dates: 1/16/89 - 1/18/89
Time: 9:00 - 5:00
City: Kapaa, Kauai, Hawaii
Place: Sheraton Coconut Beach Hotel
REGISTRATION FEE: $75 Payable to: LUCID, Inc.
ISO Meeting:
Dates: 1/19/89 - 1/20/89
Hotel Accomodations:
Hotel: Sheraton Coconut Beach Hotel
Address: Coconut Plantation
Phone: 808/822-3455
Directions from airport:
Turn right onto route 56 north (Kuhio Highway)
Look for the 7 mile marker and take next right (can see hotel from the
road but it is not on the main road)
Rate: $80/night
Mention: "X3J13 Standards Committee" for rate
Group Luau:
Place: Shearton Coconut Grove
Date: 1/17/89
Time: TBA
For further information contact:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
jlz@lucid.com
(415) 329-8400
!
X3J13/ISO January Meeting Registration Form
Please include check for $75.00 payable to Lucid mail to:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
(415) 329-8400
jlz@lucid.com
Name: _____________________________________________________________
Institution: ______________________________________________________
Net-Address: ______________________________________________________
Phone: ____________________________________________________________
Attend X3J13 _________ Attend ISO _________
Lunch 1/16: _________ yes _______ no
Lunch 1/17: _________ yes _______ no
Lunch 1/18: _________ yes _______ no
Luau 1/17 $38.50: _________ yes _______ no
∂15-Dec-88 1525 X3J13-mailer Hawaii registration form OOOPS!
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 15 Dec 88 15:25:46 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00611g; Thu, 15 Dec 88 15:22:51 PST
Received: by challenger id AA15067g; Thu, 15 Dec 88 15:18:58 PST
Date: Thu, 15 Dec 88 15:18:58 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8812152318.AA15067@challenger>
To: x3j13@sail.stanford.edu
In-Reply-To: Jan Zubkoff's message of Thu, 15 Dec 88 14:56:18 PST <8812152256.AA14949@challenger>
Subject: Hawaii registration form OOOPS!
Scratch the ISO meeting from the registration form. It really has been
cancelled.
---jan---
∂15-Dec-88 1715 X3J13-mailer Symbolics Cambridge office is moving
Received: from AI.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 15 Dec 88 17:15:23 PST
Date: Thu, 15 Dec 88 20:16:17 EST
From: KMP@STONY-BROOK.SCRC.Symbolics.COM
Sender: KMP@AI.AI.MIT.EDU
Subject: Symbolics Cambridge office is moving
To: X3J13@SAIL.STANFORD.EDU
Message-ID: <505706.881215.KMP@AI.AI.MIT.EDU>
The Symbolics Cambridge office (corporate HQ and R&D) is moving to
Burlington this week. Our file servers will be offline for some of
the transition and mail to me, Moon, etc. may bounce. If you get
back mail because Symbolics doesn't respond (and if it's possible,
convenient, etc.), please hang onto any bounced messages and
re-send them to us mid next week when things will (hopefully) be
back in order. Thanks very much.
∂15-Dec-88 1716 @Score.Stanford.EDU:jwilson@jaguar.Stanford.EDU [SLOAN@Score.Stanford.EDU: Theft]
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Dec 88 17:16:37 PST
Received: from jaguar.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 15 Dec 88 17:04:49-PST
Received: by jaguar.Stanford.EDU (5.51/inc-1.01)
id AA04484; Thu, 15 Dec 88 17:08:04 PST
Date: Thu, 15 Dec 88 17:08:04 PST
From: James Wilson <jwilson@jaguar.Stanford.EDU>
Message-Id: <8812160108.AA04484@jaguar.Stanford.EDU>
To: csd-list@score.stanford.edu
Subject: [SLOAN@Score.Stanford.EDU: Theft]
>From: Yvette Sloan <SLOAN@Score.Stanford.EDU>
Subject: Theft
Lynn Munday's wallet was stolen from her office this morning. This is a
reminder that if you must leave your office for any length of time, you
should close and lock your door. If you leave your door open, please
make sure your purse/wallet or other valuabe items are locked away in
your desk.
If you see any suspicious looking people roaming around the building, ask
them if you can help them find something or someone. This might help them
decide to leave the building before they get to take anything.
Anyway, a word to the wise....
∂16-Dec-88 0847 X3J13-mailer Re: [barmar@Think.COM: CommonLisp/C interface]
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 16 Dec 88 08:47:33 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa05376; 16 Dec 88 16:11 GMT
Date: Fri, 16 Dec 88 16:22:55 GMT
Message-Id: <7682.8812161622@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: [barmar@Think.COM: CommonLisp/C interface]
To: kempf@sun.com, x3j13@sail.stanford.edu
In-Reply-To: kempf@com.sun's message of Thu, 15 Dec 88 09:42:08 PST
Cc: pierson <@NSS.Cs.Ucl.AC.UK:pierson@mist.encore.com>,
hbs <@sail.stanford.edu:hbs@lucid.com>
> Could you bring along a copy of this document to the Hawaii
> meeting, presuming you're coming. If not, perhaps you could let
> us know where we could get it, or mail it electronically or otherwise?
Dick Gabriel should have received a copy fro ISO. I've received
several by now, via various paths, and will try to remmeber to
bring one.
-- Jeff
∂16-Dec-88 1306 @Score.Stanford.EDU:mkatz@sesame.stanford.edu [SLOAN@Score.Stanford.EDU: Theft]
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Dec 88 13:06:34 PST
Received: from sesame.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 16 Dec 88 12:55:36-PST
Received: by sesame.stanford.edu (5.57/Ultrix2.4-C)
id AA27796; Fri, 16 Dec 88 12:52:02 PST
Date: Fri, 16 Dec 88 12:52:02 PST
From: mkatz@sesame.stanford.edu (Morris Katz)
Message-Id: <8812162052.AA27796@sesame.stanford.edu>
To: jwilson@jaguar.stanford.edu
Cc: csd-list@score.stanford.edu
In-Reply-To: James Wilson's message of Thu, 15 Dec 88 17:08:04 PST <8812160108.AA04484@jaguar.Stanford.EDU>
Subject: [SLOAN@Score.Stanford.EDU: Theft]
Date: Thu, 15 Dec 88 17:08:04 PST
From: James Wilson <jwilson@jaguar.Stanford.EDU>
>From: Yvette Sloan <SLOAN@Score.Stanford.EDU>
Subject: Theft
Lynn Munday's wallet was stolen from her office this morning. This is a
reminder that if you must leave your office for any length of time, you
should close and lock your door. If you leave your door open, please
make sure your purse/wallet or other valuabe items are locked away in
your desk.
Merely locking things in ones office is not sufficient. A number of people,
myself included, have had things stolen from locked offices this term.
Unfortunately, it seems that one just can't store things one would like to keep
in MJH.
Morry Katz
katz@polya.stanford.edu
∂16-Dec-88 1313 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Undecidability of containment
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Dec 88 13:13:37 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA14965; Fri, 16 Dec 88 13:12:58 PDT
Message-Id: <8812162112.AA14965@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Fri, 16 Dec 88 13:13:27 PST
Received: by BYUADMIN (Mailer R2.01A) id 9809; Fri, 16 Dec 88 14:11:37 MST
Date: Fri, 16 Dec 88 15:06:06 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Sanjeev Mahajan <mahajan%CMPT.SFU.CDN@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Sanjeev Mahajan <mahajan%CMPT.SFU.CDN@Forsythe.Stanford.EDU>
Subject: Undecidability of containment
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
There is a problem in the Automata theory book by Hopcroft and Ullmann, which
states that if P =! NP, then it is undecidable to determine if a given
problem (or language) in NP is in P. Can anyone provide any references
to me in this regard? Thanks in advance.
∂16-Dec-88 1315 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: TCS geneology
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Dec 88 13:15:44 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA15064; Fri, 16 Dec 88 13:15:14 PDT
Message-Id: <8812162115.AA15064@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Fri, 16 Dec 88 13:15:43 PST
Received: by BYUADMIN (Mailer R2.01A) id 0096; Fri, 16 Dec 88 14:14:05 MST
Date: Fri, 16 Dec 88 15:08:54 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Judy Goldsmith <goldsmit%CS.WISC.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Judy Goldsmith <goldsmit%CS.WISC.EDU@Forsythe.Stanford.EDU>
Subject: Re: TCS geneology
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
It is official. I finally handed in my dissertation, so I am officially
PhD'd. Advisor: Deborah A. Joseph; graduation date: Dec, 1988.
First job: John Welsey Young Research Instructor, Dartmouth.
Me: Judy Goldsmith.
University: University of Wisconsin-Madison
Dept: Mathematics
∂16-Dec-88 1319 JONES@Score.Stanford.EDU Winter quarter AI classes
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Dec 88 13:19:05 PST
Received: from Score.Stanford.EDU by csli.Stanford.EDU (4.0/4.7); Fri, 16 Dec 88 13:15:15 PST
Date: Fri 16 Dec 88 13:15:05-PST
From: "H. Roy Jones" <JONES@Score.Stanford.EDU>
Subject: Winter quarter AI classes
To: ssp-faculty@CSLI.Stanford.EDU, ssp-students@CSLI.Stanford.EDU
Message-Id: <12454955706.20.JONES@Score.Stanford.EDU>
Winter quarter AI courses of interest:
CS322 AUTONOMOUS AGENT ARCHITECTURE
A rigorous treatment of the problems involved in building intelligent agents
that interact with the physical world. Topics: the representation of knowledge
about states, actions, and procedures, simulation and planning, and knowledge
level agents.
Prerequisites: 157, 221
Instructor: Mike Genesereth
MWF 1:15 in Skilling Aud
3 units
CS323 NONMONOTONIC REASONING
(Same as Philosophy 326) Formalisms for representing nonmonotonic
reasoning and their applications to AI. Nonmonotonic aspects of commonsense
knowledge and reasoning. Default logic, autoepistemic logic and
circumscription. Computational nonmonotonic reasoning. Applications of
nonmonotonic formalisms to inheritance systems, to logic programming, and
to reasoning about action using the situation calculus.
Prerequisites: A basic knowledge of logic.
Instructor: John McCarthy
TTh 2:45-4:00 in Skilling Aud
3 units
CS325 PLANNING METHODS IN ARTIFICIAL INTELLIGENCE
Introduction to AI methods for planning courses of actions in order to
achieve a specified goal from an initial state of the world. Methods
linear planning (means-ends analysis, goal regression), non-linear planning,
hierarchical planning, and compromise-based planning. Underlying problems-
frame, qualification, prediction, and persistence, and notions, such as
interdependent subgoals, are reviewed and analyzed. Two parts: the basics
illustrated with simple examples; and applications in various domains
(robotics, process planning, etc.).
Prerequisite: CS221
Instructor: Jean-Claude Latombe
TTh 1:15-2:30 in Terman 156
3 units
CS327B INTRODUCTION TO COMPUTER VISION
Visual perception by computer: formation of the image of a surface patch;
surface reflectivity; cameras and range sensors; statistical estimation.
Three-dimensional vision: local geometry of a surface patch; global surface
geometry; segmentation of surface data; stereo vision and motion perception.
Image segmentation: edge operators and extended curves; texture.
Interpretation: shape representation and geometric modeling; interpretation of
line drawings; structural matching. Comparisons are made with psychophysics.
Prerequisites: 106A, Statistics 115 or 116, Math. 103 or 113, and orthogonal
polynomials.
Instructor: Tom Binford
TTh 1:15-2:30 in ERL 320
3 units
CS429 Representing Large Bodies of Knowledge:
Issues in Representation, Inference, and Ontology
Douglas B. Lenat (Principal Scientist and Director of AI at MCC)
Mondays, 2:15 - 5:05 Building 50, Room 51P
2 Units (course will meet 2 out of every 3 Mondays)
Survey of representation "thorns", such as time, substances, space, belief,
desire, hypotheticals, intentionality. Identifying, for each of those, the
special cases that most frequently occur in our everyday dealings with
the real world; and discussing ways to adequately handle those cases.
Using the same empirical approach to develop a global ontology -- a set
of primitive objects and predicates, and rules for creating new categories,
individuals, and attributes. And using the same approach to produce a
hierarchy of useful templates for inference.
The MCC CYC project will be covered in detail. That large (two
person-century), long (1984-94) project is attempting to codify the
millions of facts, heuristics, representations, models, inference
templates, etc., that comprise human consensus reality. Such a KB could
play a key role in supporting natural language understanding, machine
learning, and non-brittle expert systems of the future.
CYC will be used to help anchor the discussions, focusing them on
problems that "really occur" and on approaches to solutions that are
"pragmatically adequate". Our approach has recently been branded as
"too scruffy" by Neats, and "too neat" by Scruffies, so perhaps we are
on the right track.
-------
∂16-Dec-88 1352 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Call for papers FOCS 89
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Dec 88 13:52:43 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA17552; Fri, 16 Dec 88 13:52:05 PDT
Message-Id: <8812162152.AA17552@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Fri, 16 Dec 88 13:52:29 PST
Received: by BYUADMIN (Mailer R2.01A) id 1091; Fri, 16 Dec 88 14:48:26 MST
Date: Fri, 16 Dec 88 15:21:16 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Zvi Galil <galil%CS.COLUMBIA.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Zvi Galil <galil%CS.COLUMBIA.EDU@Forsythe.Stanford.EDU>
Subject: Call for papers FOCS 89
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
-------------------------------------------------------------------------
CALL FOR PAPERS
1989 IEEE Symposium on
Foundations of Computer Science
The 30th Annual IEEE Symposium on Foundations of Computer Science will be
held at the Sheraton Imperial Hotel, Research Triangle North Carolina
October 30 - November 1, 1989. The Symposium is sponsored by the IEEE Computer
Society's Technical Committee on Mathematical Foundations of Computing.
Papers presenting original research on theoretical aspects of computer
science are sought. Topics include but are not limited to the following:
Algorithms and Data Structures Databases
Automata and Formal Languages Logic in Computer Science
Computability and Complexity Theory Machine Learning
Computational Geometry and Robotics Parallel and Distributed Computation
Cryptography VLSI Computation and Design
Persons wishing to submit a paper should send 15 copies of an extended
abstract by May 2, 1989 to the Program Committee chair:
Zvi Galil
Department of Computer Science
Columbia University
450 CS Building
500 West 120-th St.
New York, New York 10027
Submissions or revisions received after May 2, 1989 will not be considered.
Authors will be notified of acceptance or rejection by June 30, 1989. A
camera-ready copy of each accepted paper, prepared in a special format for
inclusion in the Symposium proceedings, will be due by August 15, 1989.
Submission format: Abstracts should begin with a succinct statement of
the problems that are considered in the paper, the main results achieved,
an explanation of the significance of the work, and a comparison to past
research. This material should be readily understandable to non-specialists.
Technical development, directed toward the specialist, should follow as
appropriate. The entire extended abstract must not exceed 2500 words or
10 double-spaced pages. Abstracts deviating significantly from these
guidelines will not be considered.
Meeting format: Authors of accepted papers will be expected to present
their work at the Symposium. The format of the meeting, including time
allocations for presentations and scheduling of sessions, will be
determined by the Program Committee. The Program Committee plans to accept
substantially more papers than in previous years and will compose a program
of parallel sessions, if warranted by the quality of the submitted papers.
Machtey Award for Best Student Paper: This award of up to $400, to help
defray the expenses for attending the Symposium, will be given for that
paper which the Program Committee judges to be the most outstanding paper
written solely by a student or students. To be considered for the award,
an abstract must be accompanied by a letter identifying all authors as
full-time students at the time of submission. At its discretion, the
Committee may decline to make the award or may split the award among two
or more papers.
Conference Chair: Program Committee Chair: Local Arrangements Chair:
Christos Papadimitriou Zvi Galil John Reif
EE&CS Department Computer Science Dept. Computer Science Dept.
University of California, 450 CS Building Duke University
San Diego Columbia University 04 North Build.
La Jolla, CA 92037 New York, NY 10027 Durham, NC 27706
Program Committee:
Alok Aggarwal Charles Leiserson Ray Strong
Eric Bach Rohit Parikh Robert Tarjan
Zvi Galil Nicholas Pippenger Mihalis Yannakakis
Juris Hartmanis Charles Rackoff Frances Yao
∂16-Dec-88 1448 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Distr.Comp.Workshop France, Corrected Version
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Dec 88 14:48:47 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA19990; Fri, 16 Dec 88 14:48:19 PDT
Message-Id: <8812162248.AA19990@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Fri, 16 Dec 88 14:48:47 PST
Received: by BYUADMIN (Mailer R2.01A) id 2425; Fri, 16 Dec 88 15:45:55 MST
Date: Fri, 16 Dec 88 15:23:32 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Paul Vitanyi <paulv%CWI.NL@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Paul Vitanyi <paulv%CWI.NL@Forsythe.Stanford.EDU>
Subject: Distr.Comp.Workshop France, Corrected Version
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
-------------------Corrected Version, Especially the Deadlines----------------
3rd INTERNATIONAL WORKSHOP
ON
DISTRIBUTED ALGORITHMS
Nice, September 26-28, 1989
Following the two first successful Workshops on Distributed Algo-
rithms in Ottawa (1985) and Amsterdam (1987), the third workshop
of this kind will be held at La Colle-sur-Loup, near Nice,
France. The workshop is intended to provide a forum for research-
ers and other parties interested in distributed algorithms on
communication networks, graphs and decentralized systems. The
aim is to present recent research results, explore directions for
future research, and identify common fundamental techniques that
serve as building blocks in many distributed algorithms.
Papers are solicited describing original results in all areas of
distributed algorithms and their applications, including e.g.
- distributed combinatorial algorithms
- distributed optimization algorithms
- distributed graph algorithms
- routing algorithms
- distributed algorithms for control and communication
- design of network protocols
- distributed database techniques
- algorithms for transaction management
- distributed algorithms for decentralized systems
- composition of distributed algorithms
- fail-safe and fault-tolerant distributed algorithms
- analysis of distributed algorithms
Intended contributors are invited to submit 8 copies of a full
paper (not exceeding 12 pages) to one of the scientific chairmen.
Jean-Claude Bermond Michel Raynal
LRI, Bat 490 IRISA
Universite Paris-Sud Campus de Beaulieu
91405 Orsay, France 35042 Rennes, France
e-mail bermond@FRLRI61.BITNET e-mail raynal@irisa.fr (uucp)
or bermond@lri.lri.fr (uucp)
Submissions must arrive before April 25, 1989. Authors will be
notified of acceptance or rejection by June 12, 1989. Proceedings
will be published, possibly in the Springer Verlag series Lec-
tures Notes in Computer Science. The final version of accepted
papers must arrive in camera-ready form before July 5, 1989, to
ensure the availability of the proceedings at the conference.
PROGRAM COMMITTEE
J-C Bermond (CNRS, LRI Orsay, France)
F. Mattern (U. Kaiserslautern, Germany)
M. Raynal (IRISA, Rennes, France)
N. Santoro (Carlton University, Ottawa, Canada and Universita` di
A. Segall (Technion, Haifa, Israel)
S. Toueg (Cornell University, Ithaca, USA)
P. Vitanyi (C.W.I. and University of Amsterdam, Amsterdam, Nether
Organizing chairman :
C. Lavault
INRIA
Domaine de Voluceau, Rocquencourt,
BP 105, 78153 Le Chesnay, France
e-mail lavault@seti.inria.fr
General Information
The workshop will be held at a French Holyday Center VVF, Chemin
de Montmeuille, 06480, La Colle-sur-Loup, France. This small
"provencal village" is located in a pine forest near Saint-Paul
de Vence, at 12 km from Nice Airport, 20 km from Cannes and 6 km
from the mediterranean sea. Further details will be mailed with
the second announcement. For further information contact either
J-C Bermond, C. Lavault, M. Raynal, or any member of the program
committee.
Please fill up this form and send it to:
J-C. Bermond, Informatique,
bat 490,Universite Paris-Sud
91405 ORSAY FRANCE
NAME:
ADDRESS:
e-mail address (if available ):
I intend to submit a paper: yes no maybe
I want to receive the second announcement: yes no
∂16-Dec-88 1547 HEMENWAY@Score.Stanford.EDU more proposals
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Dec 88 15:46:45 PST
Mail-From: GENESERETH created at 16-Dec-88 15:03:37
Date: Fri 16 Dec 88 15:03:37-PST
From: Mike Genesereth <GENESERETH@Score.Stanford.EDU>
Subject: more proposals
To: hemenway@Score.Stanford.EDU
Message-ID: <12454975464.40.GENESERETH@Score.Stanford.EDU>
ReSent-Date: Fri 16 Dec 88 15:44:13-PST
ReSent-From: Sharon Hemenway <HEMENWAY@Score.Stanford.EDU>
ReSent-To: faculty@Score.Stanford.EDU
ReSent-Message-ID: <12454982856.38.HEMENWAY@Score.Stanford.EDU>
In its last meeting last year, the Phd program committee discussed
and approved a new requirement for students in the Phd program.
Before we can put this policy into effect, we need your approval
(or, at least, your lack of non-approval).
The proposed policy is an augmentation of the reasonable progress
guidelines. In particular, we propose to require that each student in
each quarter (except for first year students in their first quarters)
conduct the equivalent of at least 9 credit hours of research (whether
for credit, as a research assistant, or both). To attest to this
work, we propose to require that each student at the end of each
quarter (except the first quarter of the first year) submit a form
signed by faculty member in which the student describes the research
done that quarter to fulfill this requirement. The description need
be no more than a paragraph long.
There are two primary reasons for this little addition to our policy.
First of all, we believe that the increasing average time to
graduation is a result, in part, of the amount of time students spend
getting started on research. Many students do not even begin to
think about research until comps and sometimes quals are out of the
way. By starting on research (of even a simple sort) earlier
in their careers here, they will be ready to embark on thesis work earlier.
Of course, many students do start their research earlier, in which case
the proposed policy has no effect but causes no problems either.
The second reason for the policy (actually for the form) is to
help both students and faculty members to know who is supervising whom
during each quarter. In past review meetings, I have too frequently
seen faculty memebrs surprised about the students for whom they
are listed as advisors.
There was really very little disagreement with this proposal in our
discussion, mostly a discussion of the reporting format. We decided
on a 2 part form. First paragraph (written by student) agreed to by
both student and advisor at beginning of the quarter states
expectations for that quarter's research. Second paragraph (also
written by student) summarizes the research actually done. The work
actually done may depart from what was planned, so long as (1) it is
agreed to by the faculty member verbally and (2) it is RESEARCH. In
other words it is okay to change direction during the quarter, but it
is NOT okay to substitute other things for research. For example, not
acceptable is a paragraph that say ``Too busy because I was preparing
for the comps''.
Comments?
-------
∂16-Dec-88 1613 @Score.Stanford.EDU:jcm@ra.stanford.edu PhD proposal
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Dec 88 16:13:23 PST
Received: from ra.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 16 Dec 88 16:10:38-PST
Received: by ra.stanford.edu (5.59/25-eef) id AA01885; Fri, 16 Dec 88 16:11:04 PDT
Date: Fri, 16 Dec 88 16:11:04 PDT
From: John Mitchell <jcm@ra.stanford.edu>
Message-Id: <8812170011.AA01885@ra.stanford.edu>
To: GENESERETH@Score
Subject: PhD proposal
Cc: faculty@score
Basically, I support the proposal. As I imagine implementing it
with my own students, I would ask for one or two sentences at
the beginning of the quarter (e.g., "I will read about category
theory and think about ...") and a statement of similar length
at the end. For beginning students, I would think that a list of
research seminars they intend to go to would be sufficient.
One part of the proposal that bothers me is the degree to which
the final paragraph is "required" to agree with the first.
If a student decides he/she is not interested in the things I
spend too much time on, that might be a valuable learning experience
(to be cliche). It is not clear from the proposal what happens if
a student ends up saying ``Too busy because I was preparing
for the comps''. Without some specific (and easy to implement)
standard course of action, this proposal might just end up creating
more work for everyone, with little useful result. (Is it necessary
to legislate "good practice" as part of departmental policy?)
I am also reminded of a student statement at one of the recent
student gripe sessions. Whoever it was said, "if you add more
research requirements [early on in the program], you had
better lessen the examination requirements." I can hear someone
saying this again.
John
∂16-Dec-88 1656 @Score.Stanford.EDU:baskett@SGI.COM [SLOAN@Score.Stanford.EDU: Theft]
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Dec 88 16:56:39 PST
Received: from amadeus.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 16 Dec 88 16:15:20-PST
Received: from SGI.COM by amadeus.Stanford.EDU (5.59/inc-1.0)
id AA09509; Fri, 16 Dec 88 16:15:34 PDT
Received: from baskett.sgi.com by sgi.sgi.com (5.52/880418.SGI)
(for jwilson@jaguar.stanford.edu) id AA26524; Fri, 16 Dec 88 16:15:04 PST
Received: by baskett.sgi.com (5.52/880418.SGI)
(for csd-list@score.stanford.edu) id AA10937; Fri, 16 Dec 88 16:14:59 PST
Message-Id: <8812170014.AA10937@baskett.sgi.com>
To: jwilson@jaguar.stanford.edu
From: mkatz@sesame.stanford.edu (Morris Katz)
Date: Fri, 16 Dec 88 12:52:02 PST
Cc: csd-list@score.stanford.edu
In-Reply-To: James Wilson's message of Thu, 15 Dec 88 17:08:04 PST <8812160108.AA04484@jaguar.Stanford.EDU>
Subject: [SLOAN@Score.Stanford.EDU: Theft]
Date: Thu, 15 Dec 88 17:08:04 PST
From: James Wilson <jwilson@jaguar.Stanford.EDU>
>From: Yvette Sloan <SLOAN@Score.Stanford.EDU>
Subject: Theft
Lynn Munday's wallet was stolen from her office this morning. This is a
reminder that if you must leave your office for any length of time, you
should close and lock your door. If you leave your door open, please
make sure your purse/wallet or other valuabe items are locked away in
your desk.
Merely locking things in ones office is not sufficient. A number of people,
myself included, have had things stolen from locked offices this term.
Unfortunately, it seems that one just can't store things one would like to keep
in MJH.
Morry Katz
katz@polya.stanford.edu
∂16-Dec-88 1821 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu #P-complete problem
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Dec 88 18:21:37 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA00860; Fri, 16 Dec 88 18:21:04 PDT
Message-Id: <8812170221.AA00860@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Fri, 16 Dec 88 18:21:34 PST
Received: by BYUADMIN (Mailer R2.01A) id 7222; Fri, 16 Dec 88 19:19:45 MST
Date: Fri, 16 Dec 88 20:16:30 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Dan Pehoushek <pehoushe@GANG-OF-FOUR.STANFORD.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Dan Pehoushek <pehoushe@GANG-OF-FOUR.STANFORD.EDU>
Subject: #P-complete problem
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Does anyone have an analytic calculation for the number of distinct
hamiltonian circuits in an nxn grid, when n is even? The grid looks
like a go board, except that a go board is 19x19. In general, this
problem is #P-complete.
The table I have so far compiled is:
#distinct solutions
2x2: 1
4x4: 6
6x6: 1072
8x8: 4638576
10x10: 467260456608
The table was derived experimentally, not analytically. Can anyone
verify this table?
By the way, the algorithm is definitely non-polynomial.
Thanks, in advance. -dan
∂16-Dec-88 1837 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu AMAST -- Second Call for Abstracts
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Dec 88 18:37:29 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA01475; Fri, 16 Dec 88 18:37:00 PDT
Message-Id: <8812170237.AA01475@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Fri, 16 Dec 88 18:37:29 PST
Received: by BYUADMIN (Mailer R2.01A) id 7351; Fri, 16 Dec 88 19:34:39 MST
Date: Fri, 16 Dec 88 20:18:13 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Chic Rattray <cr%CS.STIR.AC.UK@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Chic Rattray <cr%CS.STIR.AC.UK@Forsythe.Stanford.EDU>
Subject: AMAST -- Second Call for Abstracts
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
-------------------------------------------------------------------------
Second CALL FOR ABSTRACTS
International Conference on
Algebraic Methodology And Software Technology, AMAST
Iowa City, Iowa, May 22-24, 1989
The goal of the conference is to consolidate the trend of using algebraic
methodology as a foundation for software technology showing that universal
algebra provides a practical mathematical alternative to ad hoc approaches
used in software development. Both academia and industry are the benefici-
ary of such a formal foundation.
In order to achieve this goal, we plan to bring together leading research-
ers in mathematics and computer science on a common platform so that alge-
braic methodologies that can be used as a viable alternative to ad hoc
approaches for software development can be identified and the appropriate-
ness of such alternatives in view of actual implementations can be dis-
cussed.
Talks reporting research in algebra suitable as a foundation for software
technology as well as software technologies developed by means of algebraic
methodologies are welcome. We invite you to submit a two page abstract
(including a few citations of relevant work) of your talk to the address
AMAST CONFERENCE
Computer Science and Mathematics Departments
The University of Iowa
Iowa City, IA 52242, U.S.A.
Important due dates:
(1) Two page abstract submission by February 1, 1989.
(2) Notification of acceptance by March 15, 1989.
(3) Abbreviated four page camera ready papers to be published in proceed-
ing by April 10, 1989.
A special issue of the journal ``Theoretical Computer Science'' will
be dedicated to this conference and each participant will be invited to
submit a full paper for publication. In addition, four page abreviated
papers of the talks presented at the conference together with the invited
talks will be published in the proceedings that will be available to the
attendees upon their arrival in Iowa City. Further information can be
obtained from:
In Europe: In U.S.A: In Canada:
-------------------------------------------------------------------------
Prof. Maurice Nivat Prof. Eugene Madison, Math. Prof. Dan Ionescu
Universite Paris Prof. Teodor Rus, Comp.Sci. University of Ottawa
Place Jussieu University of Iowa Department of Elect. Eng.
75005 Paris, France Iowa City, IA 52242 770 King Edward, Ottawa
Phone: (1) 43259874 Phone: (319)-335-0694 Ont. Canada K1N 6N5
e-mail:rus@herky.cs.uiowa.edu Phone: (613)-564-2211
Prof Charles Rattray e-mail:
Computing Science Dpt. diopb@uottawa.BITNET
University of Stirling
Stirling, Scotland FK9 4LA.
e-mail: cr%compsci.stirling.ac.uk@nss.cs.ucl.ac.uk
The conference will be held at the Conference Center of the University of
Iowa. The Center for Conferences and Institutes will handle hotel reserva-
tion and registration. A block of rooms in the student dormitory will be
available at about $15 a night. A limited number of rooms at the Iowa
Memorial Union guest house at $40 a night are also reserved. For more
information contact:
Bobby C Davis
Center for Conferences and Institutes
The University of Iowa, Iowa Memorial Union
Iowa City, Iowa 52242
Phone (319)335-3231
Limousine services between Cedar Rapids airport and Iowa City are avail-
able.
∂17-Dec-88 1546 @Score.Stanford.EDU:RWF@SAIL.Stanford.EDU re: more proposals
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Dec 88 15:46:08 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sat 17 Dec 88 15:44:01-PST
Message-ID: <1PRyeA@SAIL.Stanford.EDU>
Date: 17 Dec 88 1544 PST
From: Robert W Floyd <RWF@SAIL.Stanford.EDU>
Subject: re: more proposals
To: GENESERETH@SCORE.STANFORD.EDU, hemenway@SCORE.STANFORD.EDU
CC: faculty@SCORE.STANFORD.EDU
[In reply to message from GENESERETH@Score.Stanford.EDU sent Fri 16 Dec 88 15:03:37-PST.]
The reasonable progress doctrines, which I believe have served us
well, are based on demonstrable accomplishments. The new proposal
is based on the undemonstrable. It is uncheckable and unenforceable.
It embodies the assumption that concentrating on one thing at a
time is never an optimal strategy for a student. I see no objection
to a student concentrating on preparation for the comp. Lack of
research experience will not limit comp performance, but lack of
breadth is likely to limit research performance. I understand
research advisors wanting to pledge their students to keep their
noses firmly to that particular grindstone, but even granting that,
what about students in a teaching quarter or onfellowship money?
I think there should be a reasonable demonstration that the proposal
is in the best interests of the students before giving it further
consideration.
∂18-Dec-88 0030 @polya.Stanford.EDU:pehoushe@Gang-of-Four.Stanford.EDU Re: #P-complete problem, the 12x12 case.
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Dec 88 00:30:09 PST
Received: from Gang-of-Four.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA25086; Sun, 18 Dec 88 00:29:28 PDT
Received: by Gang-of-Four.Stanford.EDU (5.59/25-eef) id AA03224; Sun, 18 Dec 88 00:27:30 PST
Date: Sun, 18 Dec 88 00:27:30 PST
From: Dan Pehoushek <pehoushe@Gang-of-Four.Stanford.EDU>
Message-Id: <8812180827.AA03224@Gang-of-Four.Stanford.EDU>
To: THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu,
pehoushe@GANG-OF-FOUR.STANFORD.EDU
Cc: aflb-tn@POLYA.STANFORD.EDU
In-Reply-To: Dan Pehoushek's message of Fri, 16 Dec 88 20:16:30 CST <8812170221.AA00860@polya.Stanford.EDU>
Subject: Re: #P-complete problem, the 12x12 case.
The number of hamiltonian circuits in an nxn grid for
the following cases has been found:
#distinct solutions
2x2: 1
4x4: 6
6x6: 1072 (10 seconds)
8x8: 4638576 (2 minutes)
10x10: 467260456608 (30 minutes)
12x12 1076226888605605706 (5 hours 40 minutes)
This last value was calculated in 5 hours and 40 minutes, on a single
processor of an Alliant FX-8, in Lucid Common Lisp, making heavy use
of Bignums.
I probably shouldn't be posting this (but it's exciting), because I'm
not quite ready to field many questions about it. Also, there may be
a simple analytic solution to the problem.
The algorithm is non-polynomial in general. It is useful for finding
the minimum weighted circuit, and for counting the number of circuits,
in a certain class of sparse, skinny graphs (skinny in the sense of
having small Tree-width, or small "matrix bandwidth"), although nxn
grids are not exactly skinny. -Dan Pehoushek
∂18-Dec-88 1603 LOGMTC-mailer beeson
Received: from ra.stanford.edu by SAIL.Stanford.EDU with TCP; 18 Dec 88 16:03:31 PST
Received: by ra.stanford.edu (5.59/25-eef) id AA02962; Sun, 18 Dec 88 16:02:54 PDT
Date: Sun, 18 Dec 88 16:02:54 PDT
From: John Mitchell <jcm@ra.stanford.edu>
Message-Id: <8812190002.AA02962@ra.stanford.edu>
To: logmtc@sail
Subject: beeson
Does anyone have a phone number of email address
for Michael Beeson? Sorry to bother those of you
who do not.
John
∂19-Dec-88 0922 STAGER@Score.Stanford.EDU Another Winter Quarter AI Class of Interest
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Dec 88 09:22:21 PST
Received: from Score.Stanford.EDU by csli.Stanford.EDU (4.0/4.7); Mon, 19 Dec 88 09:19:31 PST
Date: Mon 19 Dec 88 09:20:04-PST
From: Claire Stager <STAGER@Score.Stanford.EDU>
Subject: Another Winter Quarter AI Class of Interest
To: ssp-faculty@CSLI.Stanford.EDU, ssp-students@CSLI.Stanford.EDU
Office: CS-TAC 29, 723-6094
Message-Id: <12455699355.17.STAGER@Score.Stanford.EDU>
CS356 REASONING ABOUT KNOWLEDGE
Knowledge plays a crucial role in distributed systems, cryptography, and
artificial intelligence. Material examines formalizing reasoning about
knowledge and the extent to which knowledge is applicable to the areas above.
Issues: common knowledge, probabilistic knowledge, applying knowledge to
analyzing distributed systems, attainable states of knowledge, and modeling
resource-bounded reasoning.
Prerequisites: Mathematical maturity and a acquaintance with propositional
logic.
Instructor: Joe Halpern
Fridays 2:15-4:05 in 260-264
1-3 units
-------
∂19-Dec-88 0924 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: #P-complete problem, the 12x12 case.
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Dec 88 09:23:10 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA15674; Mon, 19 Dec 88 09:22:37 PDT
Message-Id: <8812191722.AA15674@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Mon, 19 Dec 88 09:23:01 PST
Received: by BYUADMIN (Mailer R2.01A) id 3365; Mon, 19 Dec 88 10:21:06 MST
Date: Mon, 19 Dec 88 09:51:02 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Dan Pehoushek <pehoushe@GANG-OF-FOUR.STANFORD.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Dan Pehoushek <pehoushe@GANG-OF-FOUR.STANFORD.EDU>
Subject: Re: #P-complete problem, the 12x12 case.
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
The number of hamiltonian circuits in an nxn grid for
the following cases has been found:
#distinct solutions
2x2: 1
4x4: 6
6x6: 1072 (10 seconds)
8x8: 4638576 (2 minutes)
10x10: 467260456608 (30 minutes)
12x12 1076226888605605706 (5 hours 40 minutes)
This last value was calculated in 5 hours and 40 minutes, on a single
processor of an Alliant FX-8, in Lucid Common Lisp, making heavy use
of Bignums.
I probably shouldn't be posting this (but it's exciting), because I'm
not quite ready to field many questions about it. Also, there may be
a simple analytic solution to the problem.
The algorithm is non-polynomial in general. It is useful for finding
the minimum weighted circuit, and for counting the number of circuits,
in a certain class of sparse, skinny graphs (skinny in the sense of
having small Tree-width, or small "matrix bandwidth"), although nxn
grids are not exactly skinny. -Dan Pehoushek
∂19-Dec-88 0930 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Bar-Ilan Symposium Announcement
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Dec 88 09:30:12 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA15944; Mon, 19 Dec 88 09:29:48 PDT
Message-Id: <8812191729.AA15944@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Mon, 19 Dec 88 09:30:14 PST
Received: by BYUADMIN (Mailer R2.01A) id 3671; Mon, 19 Dec 88 10:26:56 MST
Date: Mon, 19 Dec 88 10:01:49 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Martin Charles Golumbic <GOLUMBIC%ISRAEARN.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Martin Charles Golumbic <GOLUMBIC%ISRAEARN.BITNET@forsythe.stanford.edu>
Subject: Bar-Ilan Symposium Announcement
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
-------------------------------------------------------------------------
Bar-Ilan Symposium on the
Foundations of Artificial Intelligence
19-21 June 1989
Sponsored by the Research Institute for the Mathematical Sciences
Bar-Ilan University, Ramat Gan, Israel
Symposium Chair: Martin Golumbic
Organizing Chair: Ariel Frank
Program Committee:
Yaacov Choueka (Bar-Ilan University)
Rina Dechter (Technion)
Ariel Frank (Bar-Ilan University)
Martin Golumbic (IBM Israel Scientific Center)
David Harel (Weizmann Institute)
Daniel Lehmann (Hebrew University)
Judea Pearl (UCLA)
Uri Schild (Bar-Ilan University)
Micha Sharir (New York University)
Jonathan Stavi (Bar-Ilan University)
Bar-Ilan University, through its Center for Applied Logic and Artificial
Intelligence (CALAI) of the Research Institute for the Mathematical
Sciences, is pleased to announce its first "Symposium on the Foundations
of Artificial Intelligence" to be held June 19-21, 1989. The Symposium
will be international in scope, with invited lectures by several leading
researchers from Israel and abroad. Although a small meeting is
anticipated, with selected speakers and no parallel sessions, an attempt
will be made to open attendance to all interested research scientists.
The Bar-Ilan Symposium on the Foundations of Artificial Intelligence is
intended to become a bi-annual event which will focus on a range of
topics of concern to scholars applying quantitative, combinatorial,
logical, algebraic and algorithmic methods to AI areas as diverse as
decision support, automatic reasoning, knowledge-based systems, machine
learning, computer vision, and robotics. These include applied
logicians, algorithms and complexity researchers, AI theorists, and
applications specialists using mathematical methods. By sponsoring such
symposia, we hope to influence the spawning of new areas of applied
mathematics and the strengthening of the scientific underpinnings of
artificial intelligence.
...................... INVITED LECTURES ......................
Ron Rivest (MIT) will lecture on
"Recent Developments in Machine Learning Theory".
Joe Halpern (IBM Research) will lecture on
"Reasoning about Knowledge and Probability".
Additional invited speakers will be announced at a later date.
...................... CALL FOR PAPERS .......................
High quality research papers are solicited for consideration by the
program committee to be presented at the Symposium. Submissions of
extended abstracts of 4-10 pages or full papers must arrive by
15 March 1989 and should be sent in triplicate to:
Prof. Martin Golumbic
IBM Israel Scientific Center
Technion City
Haifa, Israel
Decisions on presentations will be made on or before 15 April 1989.
.................... REFEREED PROCEEDINGS ....................
At the conclusion of the Symposium, all participants are invited to
submit full length papers which will be refereed according the usual
standard of the best professional journals, and those accepted will be
published in a separate, special issue of the Annals of Mathematics and
Artificial Intelligence as a permanent record of the Symposium.
For further information on the Symposium and to receive additional
announcements, contact
Dr. Ariel Frank, BISFAI-89
Department of Mathematics and Computer Science
Bar-Ilan University
Ramat Gan, ISRAEL
(email: ariel@bimacs.bitnet)
∂19-Dec-88 0940 @Score.Stanford.EDU:jlh@vsop.Stanford.EDU Re: more proposals
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Dec 88 09:40:49 PST
Received: from vsop.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 19 Dec 88 09:38:32-PST
Received: from LOCALHOST by vsop.Stanford.EDU (5.59/inc-1.0)
id AA02053; Mon, 19 Dec 88 09:28:49 PDT
Message-Id: <8812191728.AA02053@vsop.Stanford.EDU>
To: Mike Genesereth <GENESERETH@Score.Stanford.EDU>
Cc: faculty@score.stanford.edu, hemenway@Score.Stanford.EDU
Subject: Re: more proposals
In-Reply-To: Your message of Fri, 16 Dec 88 15:03:37 -0800.
<12454975464.40.GENESERETH@Score.Stanford.EDU>
Date: Mon, 19 Dec 88 09:28:44 PST
From: jlh@vsop.Stanford.EDU
I believe that continually increasing the requirements for our PhD
students is a major contributor to increasing the time to graduation. For
example, the comp has become HARDER to pass than earlier, despite the
fact that the students are better prepared (i.e. they know more CS than
they did 5-10 years ago).
I don't want students dragging the comp into their second or third
year. If a first year student tells me she was too busy preparing for
the comps to get much else done, that's fine with me. Why can't the
advisor approve or disapprove what the student has written without some
other judgement about what is or isn't a valid way to spend time?
I also believe that our present mentor system is too "loose" and that a
traditional advisor relationship, but without any long-term commitment
would serve the students better.
John
P.S. As CS matures, some increase in the time to complete a PhD is
probably inevitable. This is certainly true in systems.
∂19-Dec-88 0952 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Capital City Conference
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Dec 88 09:52:08 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA16690; Mon, 19 Dec 88 09:51:44 PDT
Message-Id: <8812191751.AA16690@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Mon, 19 Dec 88 09:52:09 PST
Received: by BYUADMIN (Mailer R2.01A) id 4322; Mon, 19 Dec 88 10:46:36 MST
Date: Mon, 19 Dec 88 10:03:45 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Bob Robinson <rwr%GATECH.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Bob Robinson <rwr%GATECH.EDU@Forsythe.Stanford.EDU>
Subject: Capital City Conference
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Capital City Conference on
COMBINATORICS and THEORETICAL COMPUTER SCIENCE
MAY 22-26, 1989
at
The George Washington University, Washington, D.C.
announcement
call for papers
registration information
sponsored by the National Science Foundation
and The George Washington University
The aim of the conference is to offer a setting for relaxed and
productive professional interaction between combinatorists and
theoretical computer scientists. We will aim for substantive rather
than numerous talks, in an effort to maximize information content and
depth, and to allow time for discussions among the participants.
We hope that the conference activities will expand the participants'
research interests across the boundaries of the two disciplines, and
lead to increased collaboration between members of the two communities.
TOPICS AND PRINCIPAL SPEAKERS
graph theory
Laszlo Lovasz, Princeton University and Eotvos Lorand University
"Communication Complexity of Graph Problems"
May 22, 11:00 a.m. and 2:00 p.m., and May 23, 11 a.m.
algebraic combinatorics
Richard Stanley, Massachusetts Institute of Technology
"Applications of Algebra to Combinatorics"
May 24, 11:00 a.m. and 2:00 p.m., and May 25, 11:00 a.m.
algorithms and complexity
Richard Karp, University of California, Berkeley
"Randomized Algorithms"
May 25, 2:00 p.m. and May 26, 11:00 a.m. and 2:00 p.m.
Each principal speaker will give three lectures which will
overview the topic and will highlight major results, techniques, and open
problems. The principal speakers will be asked to provide a list of
suggested reading which will be made available to the interested
preregistrants before the time of the conference.
CALL FOR PAPERS
We will schedule 25-minute contributed talks on subjects directly
related to the conference topics and consistent with the theme of
the conference. We will do our best to accommodate
contributed talks to the extent permitted by the intent to give sufficient
time to each talk, and to have time for informal discussions among
the participants.
If you are interested in giving a contributed talk, please submit
before March 1, 1989 a two-page abstract describing the subject, background,
and main results of your paper .
In the case of joint work, please indicate which of the authors will
give the talk.
A special issue of Discrete Applied Mathematics and/or Annals of
Discrete Mathematics will be devoted to the refereed proceedings
of this conference. Complete texts of submissions must reach
Rodica Simion by June 15, 1989.
PROBLEM SESSION, Thursday, May 25, 7:30 p.m.
We invite contributions of open problems which will
generate discussions and collaborations. Please send problems,
including references, by March 1, 1989. Preregistered participants
will receive the list of problems before the beginning of the conference.
SPECIAL SESSION, Wednesday, May 24, 7:30 p.m.
Interested participants are invited to an evening discussion
on topics including funding sources for research in combinatorics and
theoretical computer science, and educational issues in combinatorics
and computer science. If you wish to suggest other discussion topics,
please do so by March 1, 1989.
PARTICIPANTS SUPPORT
Limited funds are available for partial support of participants,
in particular for graduate students.
Selection for the graduate student awards will be made based on a
description of the student's research interests and work, and two letters
of recommendation.
For full consideration, applications should be received by
March 7, 1989.
LOCAL INFORMATION
The conference talks will begin on May 22, at 9:00 a.m.,
in Marvin Center, room 402. The registration desk will open at 8:30 a.m.,
in room 410. Marvin Center is located on the GWU campus at 800 21st
Street, N.W.
We have reserved blocks of rooms at reduced rates, under
"GWU Math Dept Conference", at several hotels which are
within 10-15 min.\ walking distance of the metro station and campus.
River Inn, 924 25th Street, N.W., (202) 337-7600;$95 single/double.
Georgetown Marbury Hotel, 3000 M Street, N.W.,(202) 726-5000;
$80 single/double.
State Plaza Hotel, 2117 E Street, N.W., (202) 861-8200 or
1-800-424-2859; mention "group number 2815"; $85 single, $95 double.
Lombardy Hotel, 2019 I Street, N.W., (202) 828-2600;
$80 single, $90 double.
Please call the hotel directly and guarantee your
reservations by April 21, 1989.
After this date, the rooms will be released, and the regular rates will
apply to available rooms.
On a first come first served basis, until April 15, 1989,
rooms can be reserved in Thurston Hall, 1900 F Street, N.W.
This is a GWU dormitory with air-conditioned rooms, private bath,
and sheets/towels/etc. provided. The information on the registration
form is particularly important in signing up for dormitory space.
The rates are \$30 for single, \$20 for double occupancy.
>From National Airport, take the metro Blue Line to the GWU/Foggy
Bottom stop, which is at 23rd St. and I St., N.W. Cab rides from
National and Dulles Airports are approx. $10 and $30, resp. From
Union Station, take the metro Red Line to Metro Center, change to the Blue
Line, and get off at GWU/Foggy Bottom. Cab rides from Union Station are
approx. $5.
May weather in Washington is pleasant, with average highs of
68F and lows of 58F. May is also a popular camping time.
Attractive camping facilities exist at Greenbelt Park (National Park
Service), (301) 344-3948.
REGISTRATION
To register, please send your completed registration form, or facsimile,
and check to the address on the form.
Refunds, less \$10, will be made if a written request is received by
May 10, 1989.
MAIL and FURTHER INQUIRIES
Regarding the problem/special session, please contact
Louis Shapiro, Mathematics Department, Howard University, Washington,
D.C. 20059, (202) 636-7125; regarding other matters, please contact Rodica
Simion, Department of Mathematics, George Washington University, Washington,
D.C. 20052; (202) 994-6238; simion@gwuvm.bitnet
REGISTRATION FORM
The following information will be very helpful in planning the
conference events.
Full name .................................................
.......................................... Title .............................
Business address ........................................
........................................ Phone (B).........................
......................................................
.................................................... Phone (H)................
City .......................... State ...... Zip Code ............
e-mail address ................................................................
Registration fee: $80 if received by April 15, 1989;
$95 after April 15, 1989. Amount enclosed $ ...............
During the conference I will stay at Marbury ........ River Inn ........
Lombardy ......... State Plaza ..........
Other ..........................................
Arrival time ........................
Departure time .........................
I wish to request a dormitory room.
I wish to share a room: yes .... no .... no preference ......
Sex F ........ M ........
My roommate should be smoker ...... non-smoker ....... no preference .......
For dormitory space, please send a separate check for the full
amount. Please make your check(s) payable to The George Washington
University, and mail your check(s) and registration form to Rodica Simion,
Department of Mathematics, George Washington University, Washington,
D.C. 20052.
chairperson
Rodica Simion, George Washington University
program committee
Ira Gessel, Brandeis University
Robert W. Robinson, University of Georgia
Michael Saks, University of California, San Diego
organizing committee
Hosam Mahmoud, George Washington University
Louis Shapiro, Howard University
Dan Ullman, George Washington University
∂19-Dec-88 1030 DEWERK@Score.Stanford.EDU CS-TAC Shutdown.
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Dec 88 10:30:17 PST
Date: Mon 19 Dec 88 10:21:58-PST
From: Gerda de Werk <DEWERK@Score.Stanford.EDU>
Subject: CS-TAC Shutdown.
To: csd-list@Score.Stanford.EDU
cc: dewerk@Score.Stanford.EDU
Message-ID: <12455710623.29.DEWERK@Score.Stanford.EDU>
The CS-TAC offices will be closed 12/20-12/23, while power for the
Tresidder deck addition is installed. CS-TAC offices, LOTS-II, the
Recreation Desk, and the Coffee House will be closed from 7:30am
Tuesday, 12/20, until Friday afternoon (12/23).
Please send electronic mail to CS-TAC occupants if you need to
communicate with them during this time.
Gerda
-------
∂19-Dec-88 1114 @polya.Stanford.EDU:mendel@ois.db.toronto.edu Positions in Toronto
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Dec 88 11:14:40 PST
Received: from [128.100.1.161] by polya.Stanford.EDU (5.59/25-eef) id AA20419; Mon, 19 Dec 88 11:12:46 PDT
Received: by ois.db.toronto.edu id 9269; Mon, 19 Dec 88 14:11:48 EST
From: Alberto Mendelzon <mendel@db.toronto.edu>
To: nail@navajo.stanford.edu
Subject: Positions in Toronto
Message-Id: <88Dec19.141148est.9269@ois.db.toronto.edu>
Date: Mon, 19 Dec 88 14:11:46 EST
The Computer Science Department at the University
of Toronto is looking for research associates
and postdoctoral fellows. The area of
databases/knowledge bases is of particular interest.
There is also a tenure-stream faculty appointment to
be made jointly to the Faculty of Library and Information
Sciences and the Department of Computer Science.
For more information, contact:
Alberto Mendelzon
mendel@db.toronto.edu
416-978-2952
Or apply directly to:
Prof. Derek Corneil
Department of Computer Science
University of Toronto
Toronto, Ontario M5S 1A4
Canada
∂19-Dec-88 1426 @Score.Stanford.EDU:dill@amadeus.Stanford.EDU Re: more proposals
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Dec 88 14:26:32 PST
Received: from amadeus.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 19 Dec 88 14:23:34-PST
Received: by amadeus.Stanford.EDU (5.59/inc-1.0)
id AA13195; Mon, 19 Dec 88 14:23:32 PDT
Date: Mon, 19 Dec 88 14:23:32 PDT
From: dill@amadeus.Stanford.EDU (David Dill)
Message-Id: <8812192223.AA13195@amadeus.Stanford.EDU>
To: faculty@score.stanford.edu
Subject: Re: more proposals
GETTING AN EARLY START IN RESEARCH
We ought to be structuring the PhD program to maximize the quality and
quantity of the research that the students do during their time here.
It is important for students to start research early for
several reasons:
* Getting up to speed in a research area takes time (typically a
year or so).
* Some students spend a great deal of time shopping for a research
area they are interested in. The best way to decide interestedness
(or develop it) is to work on research problems in an area.
* It takes many students some time to shift gears from meeting
preset goals to setting their own, and from understanding to
creativity.
* Some students are ultimately not interested in doing research
(even if they think they are). The sooner they discover this,
the less of everyone's time they will waste.
As nearly as I can tell from talking to some of the students, the
message that they are getting is that research in the first year is
neither required nor rewarded -- the only things that matter are the
comps. This is the wrong message for us to be sending. Their
primary purpose here is to do research and become researchers.
Supervising first year students is an investment that may pay off
later, but it is important for the health of the program. (Although
in some cases first year students will be very productive.)
RESEARCH REQUIREMENT
If we want students to do some research in addition to the comps, and
the comps are required, there should also be a research requirement
(otherwise, it is easy to see which activity will go by the wayside).
I have talked to several students about why the first year students
don't get involved in research, and sometimes don't even talk to
faculty. The answer in both cases was: "They're scared. They hear
about students getting booted because they didn't pass the comps."
Even if students are chafing at the bit to get start on research, they
don't, because of this perception.
This is not to say that comps are unimportant. As Bob Floyd has
pointed out, understanding (much of) the material on the comps is
crucial for sustaining research. I believe that students should
be spending the majority of their time on comps. But the
majority of their time is not ALL of their time.
It is also unreasonable to expect that all students will have, for
example, publications at the end of their first year. I think it IS
reasonable to expect that students have some insights about
interesting research problems in an area, some background as to what
has already been done, and some ideas about what they would like to
do. Their advisor would be the best judge of this sort of progress.
RESEARCH ADVISORS
It is unreasonable to have a research requirement unless students have
research advisors. I am very unhappy with the current mentor system.
The message to the students is that a mentor is something less than an
advisor. Perhaps the message to the faculty is the same -- that
serving as a mentor should not be as great a commitment as serving as
an research advisor.
Students often do not realize the importance of advisors.
(I speak from personal experience.)
I was appalled when a second year student told me that since he
was on a fellowship, he didn't need an advisor. He planned
to "shop around" for an interesting research project while he
worked on his remaining comps and qual. I have a feeling that
he is not shopping very intensely. Instead, he is falling through
the cracks.
Students should be required to have advisors, not mentors,
as soon as is reasonable, whether they have fellowships or not.
COMPS
If we add some requirements in the first year, we should remove some
others. The comps are an obvious target.
The basic arguments for the comps, that our students have a broader
background than those of some other schools, and that a good general
grounding in computer science is essential for sustained research, are
valid. However, I feel that they can be somewhat scaled back with
good effect.
There is obviously a tradeoff between time spent on the comps and time
spent on research. (I resented it when my student had to study for
the Graphics comp instead of reading about his area or helping me
with a paper.) However, I don't see that the forces determining
the scope and size of the comps reflect this tradeoff.
PROPOSALS
The research requirement proposal is a good start. It should be
coupled with the more important requirement that every student have a
faculty research advisor (say, by the end of the first quarter). No
more mentors. Furthermore, it is essential that the comps be scaled
back significantly. This means reducing the size of the exams in some
cases and reducing the readings in others.
Finally, students should be fill out a short form at the end of the
first year (maybe in the middle of the year, too) saying what they
have accomplished in different areas: exams passed, papers published,
research they have worked on, and other. Students should understand
that if there are other ways to excel in their first year than
doing exams, and that suboptimal performance in one area can
be compensated for by better performance in other areas.
Ideally, this would introduce more flexibility into the program.
Instead of being forced to devote all their time to the comps,
students can spend some on research and still no fear being
ejected from the program.
STUDENT INPUT
I'm worried that the students may not have sufficient input into this
proposal because of the timing, particularly if it is voted on in the
faculty meeting at the beginning of the Winter quarter.
SUMMARY
The current hidden curriculum strongly encourages first-year PhD
students to be nerds. In many cases, this reinforces tendencies
ingrained by years of schooling. Instead, we ought to be inculcating
more adult values: that we are judged not on our grades and exams,
but on our original contributions.
∂19-Dec-88 1519 @Score.Stanford.EDU:dill@amadeus.Stanford.EDU PhD research discussion
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Dec 88 15:19:51 PST
Received: from amadeus.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 19 Dec 88 15:17:08-PST
Received: by amadeus.Stanford.EDU (5.59/inc-1.0)
id AA13322; Mon, 19 Dec 88 15:17:10 PDT
Date: Mon, 19 Dec 88 15:17:10 PDT
From: dill@amadeus.Stanford.EDU (David Dill)
Message-Id: <8812192317.AA13322@amadeus.Stanford.EDU>
To: faculty@score.stanford.edu
Subject: PhD research discussion
Is this a private discussion among us faculty? Perhaps we should
post it on the Phd-program bboard?
∂19-Dec-88 1621 @Score.Stanford.EDU:wheaton@athena.stanford.edu visitor
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Dec 88 16:21:54 PST
Received: from athena.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 19 Dec 88 16:19:15-PST
Received: by athena.stanford.edu (5.59/25-eef) id AA03476; Mon, 19 Dec 88 16:19:18 PDT
Date: Mon, 19 Dec 88 16:19:18 PDT
From: George Wheaton <wheaton@athena.stanford.edu>
Message-Id: <8812200019.AA03476@athena.stanford.edu>
To: faculty@score
Subject: visitor
Stacey Green of the North East Asia Forum called to say that a Mr.
Sekizawa, an Executive Director of Fujitsu, will be here one day
between Jan 10 & 12. He, and the company, are supporters of Stanford.
He would like to meet with people working in image processing and
graphics.
Anyone interested and available?
gw
∂19-Dec-88 1637 @Score.Stanford.EDU:HALPERN@IBM.COM Re: research
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Dec 88 16:37:42 PST
Received: from IBM.COM by SCORE.STANFORD.EDU with TCP; Mon 19 Dec 88 16:35:10-PST
Date: 19 Dec 88 15:03:18 PST
From: "Joseph Y. Halpern" <HALPERN@ibm.com>
To: faculty@score.stanford.edu
Message-Id: <121988.150321.halpern@ibm.com>
Subject: Re: research
Although I'm somewhat of an outsider to Stanford, I felt inspired
by David Dill's comments to comment myself on the issue of students
doing research. At the risk of putting my foot in my mouth, let me
say that I have been struck be the relatively low impact Stanford
students have had in the theory community in the past 5-7 years. I
don't think it would be hard to reel off 10 Berkeley or MIT students
who have had a major impact on the STOC/FOCS community in that time
period; the same certainly can't be said for Stanford. Since I don't
think that Stanford starts with students who are any less bright than
those at MIT or Berkeley, so we have to look elsewhere for the causes.
Part of the problem very recently has been lack of advisors, but I
don't think that's the whole problem (Berkeley did pretty well with
just Karp and Blum for a long time). I would guess that the reason
lies much more in the greater emphasis on research at MIT and Berkeley.
Certainly at MIT, just before the FOCS/STOC deadlines, you see lots
of students slaving away at papers they want to submit (often with
only student coauthors). I suspect the same is true at Berkeley
(where students have historically worked with each other, due to the
lack of faculty advisors). Obviously one can't change a culture
overnight, but I would like to make two suggestions as to what can
be done. The first is to de-emphasize examwork or coursework (including
the comps). (By "de-emphasize" I mean cut down on the requirements.)
Although having a broad understanding of the field is clearly an asset
to doing research, I believe that the experience of doing research is as
important an asset, and one that gets relatively much less attention,
especially at Stanford. The second is to de-emphasize
the view of a thesis as a magnum opus. We should encourage students to
think in terms of writing papers, whether or not they are related, rather
than to think in terms of writing a thesis. My own thesis consisted of
four papers stapled together; I don't think my research career has suffered
as a result. I write papers now; not theses. The current emphasis
on writing a big thesis tends to discourage students from working
on problems that aren't part of a "big question" that can be a thesis.
I also agree that the students should be involved with this
discussion. Since I'm not sure of the appropriate address to mail
this to in order to include students, I hope that someone can post the
message on the appropriate bboard for me. Thanks.
-- Joe
∂19-Dec-88 2207 @Score.Stanford.EDU:jcm@ra.stanford.edu research
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Dec 88 22:07:14 PST
Received: from ra.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 19 Dec 88 22:05:08-PST
Received: by ra.stanford.edu (5.59/25-eef) id AA03855; Mon, 19 Dec 88 22:05:09 PDT
Date: Mon, 19 Dec 88 22:05:09 PDT
From: John Mitchell <jcm@ra.stanford.edu>
Message-Id: <8812200605.AA03855@ra.stanford.edu>
To: faculty@score
Subject: research
I basically agree with Joe Halpern. I suppose this
is not surprising, given that we had the same advisor and
4-paper staple-thesis approach. (I tried to follow his example.)
Two factors that contributed to my immediate involvment in research
at MIT were the MS thesis requirement, and the lack of emphasis on
written exams. If the current proposal to require quarterly research
contracts were balanced with a change in the comp grading procedure,
the net effect might be to encourage early research in a similar way.
At the time I was a student, everyone took a written exam,
but no one passed or failed. Grades were interpreted by an oral exam
committee that also reviewed MS thesis results, or progress
if the thesis was not completed after 3 semesters.
I also took classes in which it was typical for at
least one or two students to produce publishable papers as term
projects. I particularly remeber a database class where Christos
said that the year (or two years?) before, Kanellakis had proved
something or other in his term paper. We all felt challenged to
prove something more difficult in our own term papers, to the
extent that I skipped about 50% of the remaining lectures once
I had chosen a problem to work on. While I missed out on some of
the course material, I read quite a bit about the problem I was
working on. So I believe it all balanced out in the end.
(This may also apply to cutting comp requirements and increasing
research emphasis.)
Many students here seem perfectly content,
even in their third year, to dabble about without writing anything up.
Perhaps this is attributable to some "find yourself" California search
ethic, but it is more likely that students are not getting the proper
guidance or encouragement. Most would like to be doing reseach,
but don't seem to think they know enough to start right now.
In thinking about this, I am reminded of the session with
theory students during my interview here two years ago.
I asked them what their reactions would be if I
suggested a topic for a joint paper. Most either said they couldn't do
this now, because they had to study for comps or quals or some such
thing, or that they were surprised that as a faculty member I would
consider co-authoring a paper with a student. While I know that
faculty here do write papers with students, I think this is an
interesting indication of how some students perceive the possibility.
∂19-Dec-88 2233 @Score.Stanford.EDU:cheriton@Pescadero.Stanford.EDU Re: research
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Dec 88 22:33:06 PST
Received: from Pescadero.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 19 Dec 88 22:31:23-PST
Received: by Pescadero.Stanford.EDU (5.59/25-eef) id AA06458; Mon, 19 Dec 88 22:33:57 PDT
Date: Mon, 19 Dec 88 22:33:57 PDT
From: David Cheriton <cheriton@Pescadero.Stanford.EDU>
Message-Id: <8812200633.AA06458@Pescadero.Stanford.EDU>
To: faculty@score, jcm@ra.stanford.edu
Subject: Re: research
In-Reply-To: <8812200605.AA03855@ra.stanford.edu> from John Mitchell
<jcm@ra.stanford.edu> on Mon, 19 Dec 88 22:05:09 PDT
I really object to this discussion - it's too frightening! If we eliminated
the comps then:
1) The students would have more time to do research.
2) The faculty would have more time to advise and work with students.
3) The students would likely graduate sooner and publications coming out
of the dept. would goo up, making it look like we were working harder
to the dean and everyone else, but at something we actually enjoyed.
Isnt there a less dangerous idea to discuss?
∂19-Dec-88 2242 X3J13-mailer Corrections to the ISO Report
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 19 Dec 88 22:42:08 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA03191g; Mon, 19 Dec 88 22:39:08 PST
Received: by challenger id AA19722g; Mon, 19 Dec 88 22:35:13 PST
Date: Mon, 19 Dec 88 22:35:13 PST
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8812200635.AA19722@challenger>
To: x3j13@sail.stanford.edu
Subject: Corrections to the ISO Report
Colleagues:
There have been a couple of questions directed privately to me about
my ISO meeting report. I think the answers are of general interest, so
I will direct them to the X3J13 mailing list.
1. The first regards the Japanese position on CLOS. I believe there
are two concerns that the Japanese have: one is that the CLOS
specification is difficult to read and thus is difficult to evaluate;
the other is that CLOS is comparatively new and represents relatively
recent research, which leads them to believe that it would be good to
gather some practical experience with it before international
standardization. I believe this is a reasonable position. I believe
the US must make its case convincingly for the Japanese to agree to
adopting CLOS into a near-term international standard.
2. There was a wording problem with my comments on the AFNOR
delegation's response to the US position. The US indeed voted to
accept the New Work Item that is the basis for the establishment of
WG16. At the first meeting AFNOR proposed a work plan (which I
inaccurately referred to as a ``work item''). The proposed work plan
is to adopt Common Lisp as the starting point for IsLisp but to try to
alter Common Lisp in certain ways. The structure of the work plan is
to identify features of Common Lisp that WG16 should alter and to
associate with the feature a default. For each such feature, if no
acceptable technical alternative to the feature is determined within a
reasonable time period, the default replaces the feature. For
example, the package system is on the list of features to alter, and
if no better solution than the current Common Lisp package system is
determined, the default is to provide only a flat namespace - that is,
the default is no package system. The US did not agree to this work
plan, and the evidence for this is simply that the acceptability of
the work plan never came to a vote at WG16. Therefore, the US did not
change its position regarding this work plan, and the current US
position is the first time the US took any position with regard to the
work plan for WG16 proposed by the AFNOR delegation.
When the AFNOR delegation stated that the US position represented a
``preposterous'' change in position by the US, I interpreted their
statement as a response to an incorrectly perceived change in position
by the US regarding the never-agreed-on AFNOR-proposed work plan. The
only alternative interpretation I could think of is that the AFNOR
delegation incorrectly perceived a change in position by the US to the
New Work Item that defines the goal of WG16. Since the latter
interpretation is illogical, I adopted the other one.
3. There was a minor error in my report on the presentation by Mr
Kurokowa. The following is the amended section (the word that should
be deleted is in [square brackets]):
``Mr Kurokowa presented a report on Japanese activity on provisions
within [Common] Lisp for international character sets. Thom Linden
presented the latest X3J13 work on the same topic. In addition, the
U.S. was asked to present the current WG16 status on character
handling at the next SC22 meeting.''
That is, Mr Kurokowa discussed international character set handling
for an internationally standardized Lisp and not for Common Lisp.
-rpg-
∂19-Dec-88 2338 @Score.Stanford.EDU:eaf@sumex-aim.stanford.edu Re: more proposals
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Dec 88 23:38:25 PST
Received: from sumex-aim.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 19 Dec 88 23:36:26-PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA23232; Mon, 19 Dec 88 23:37:15 PST
Date: Mon, 19 Dec 1988 23:37:15 PST
From: Edward A. Feigenbaum <eaf@sumex-aim.stanford.edu>
To: dill@amadeus.stanford.edu (David Dill)
Cc: faculty@score.stanford.edu
Subject: Re: more proposals
In-Reply-To: Your message of Mon, 19 Dec 88 14:23:32 PDT
Message-Id: <CMM.0.88.598606635.eaf@sumex-aim.stanford.edu>
I agree wholeheartedly with Dave's message. And, in fact, that's the way
things USED TO BE! We were a research-oriented department, not a "cram-
material-for-exams" department. But there's a kind of Greshem's Law operating
in which the study-and-test mode gradually drives out the research mode.
The gold standard is research, and we should take significant steps to
return to that standard in the department.
Ed F.
∂20-Dec-88 0233 X3J13-mailer Gabriel's report
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 20 Dec 88 02:33:05 PST
Received: from relay2.cs.net by RELAY.CS.NET id ab19605; 20 Dec 88 4:03 EST
Received: from utokyo-relay by RELAY.CS.NET id ab03791; 20 Dec 88 3:58 EST
Received: by ccut.cc.u-tokyo.junet (5.51/6.3Junet-1.0/CSNET-JUNET)
id AA21505; Tue, 20 Dec 88 16:24:50 JST
Received: by nttlab.ntt.jp (3.2/6.2NTT.h) with TCP; Tue, 20 Dec 88 15:56:01 JST
Received: by tutics.tut.junet (ver3.3/6.2J/systemV)
id AA07407; Tue, 20 Dec 88 12:37:46 jst
Message-Id: <8812201237.AA07407@tutics.tut.junet>
Date: Tue, 20 Dec 88 12:37:46 jst
From: Taiichi Yuasa <yuasa%tutics.tut.junet@UTOKYO-RELAY.CSNET>
To: x3j13@SAIL.STANFORD.EDU
Subject: Gabriel's report
Cc: RPG@SAIL.STANFORD.EDU
As a secretary of Japanese SC22/LISP WG, I have some comments on Richar
d
Gabriel's report on the November ISO meeting.
> Mr. Kurokawa presented a report on Japanese activity on
> provisions within Common Lisp for international character sets.
This sentence is wrong. The Japanese SC22/LISP WG is working for
ISO standard, but NOT for Common Lisp standard. Mr. Kurokawa is
supposed to have presented (and he confirmed me that he indeed
presented) a Japanese contribution on international character
set handling within ISO standard, but not necessarily within
Common Lisp. He may have used some Common Lisp terminology, but
this is because of the WG16 agreement that Common Lisp
be a starting point.
> Professor Ito
> is primarily concerned about CLOS,
This is true. And, this is not only his personal concern, but a general
concern of Japanese Lisp WG as well. It seems to me that this is a more
general concern of the Japanese computer science community, since CLOS
has not received a citizenship in object-oriented world in Japan.
> but after private discussions I
> learned that because of lack of study he did not understand it,
This is not true. I know he fully understands CLOS. Note,
however, that it is painful to read the CLOS document, especially
when no one has officially proposed it to WG16, and when
inclusion of CLOS to ISO standard is so doubtful in one's
country.
> and
> the expert group that advises him consists of object-oriented
> programming researchers who press their own ideas on him.
I'm afraid this sentence came from Gabriel's misunderstanding or
prejudice about Japanese activities for Lisp standardization.
Prof. Ito himself is a programming expert (he is one of the first
Lisp hackers in Japan) and his opinion has been reflected to "the
expert group" to a great extent.
Programming experts including Prof. Ito himself is working very
hard for ISO standard, as well as investigating their own ideas.
To sum up, I found the sentences of Gabriel's report concerning with
Japanese activities are quite misleading. I hope my comments can
help you avoid misinterpretation of these sentences.
-- Taiichi Yuasa
∂20-Dec-88 0757 X3J13-mailer Re: Gabriel's report
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 20 Dec 88 07:57:15 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA28013; Tue, 20 Dec 88 07:59:03 PST
Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA28535; Tue, 20 Dec 88 07:55:43 PST
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
id AA18561; Tue, 20 Dec 88 07:56:17 PST
Message-Id: <8812201556.AA18561@suntana.sun.com>
To: Taiichi Yuasa <yuasa%tutics.tut.junet@UTOKYO-RELAY.CSNET>
Cc: x3j13@SAIL.STANFORD.EDU, RPG@SAIL.STANFORD.EDU
Subject: Re: Gabriel's report
In-Reply-To: Your message of Tue, 20 Dec 88 12:37:46 +0200.
<8812201237.AA07407@tutics.tut.junet>
Date: Tue, 20 Dec 88 07:56:14 PST
From: kempf@Sun.COM
>concern of Japanese Lisp WG as well. It seems to me that this is a more
>general concern of the Japanese computer science community, since CLOS
>has not received a citizenship in object-oriented world in Japan.
What, precisely, is the Japanese concern with CLOS? The committee has
made an effort over the past 2 years to remain open to suggestions
about modifying the design. There have been several electronic mail
messages from someone in Japan on the subject (it may have been Prof. Ito)
which have been taken into account during the design. What changes do
the Japanese delegates feel are needed (if any) for CLOS to receive
"full citizenship" in the Japanese object-oriented world, presuming,
of course, that Common Lisp is accepeted as an adequate base? Is there
a reasonable chance that CLOS can achieve that status, or do most
Japanese object-oriented programmers feel more confortable using Smalltalk?
jak
∂20-Dec-88 1137 X3J13-mailer access to the standard
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 20 Dec 88 11:37:37 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA29610; Tue, 20 Dec 88 11:36:35 PST
Message-Id: <8812201936.AA29610@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 20 Dec 88 14:02
To: x3j13@sail.stanford.edu
Subject: access to the standard
Following is the updated account information for accessing the
working draft of the standard:
Username: ftp_user
Password: merrychristmas
Node: hudson@dec.com
The password has changed.
kc
∂20-Dec-88 1301 @Score.Stanford.EDU:tah@linz PhD Requirements & Research
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Dec 88 13:01:41 PST
Received: from linz.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 20 Dec 88 12:59:45-PST
Received: by linz.stanford.edu (5.59/25-eef) id AA05797; Tue, 20 Dec 88 12:56:38 PDT
Message-Id: <8812202056.AA05797@linz.stanford.edu>
To: faculty@score
Subject: PhD Requirements & Research
Reply-To: tah@cs.stanford.edu
Date: 20 Dec 88 12:56:35 PST (Tue)
From: Tom Henzinger <tah@linz>
Does anyone object if I forward the entire discussion to the PhD program
bboard, so that the students are able to follow and join?
In general, it is a welcome idea to cc messages about the PhD requirements
and on how to do research to phd-program@score; that would save the student
bureaucrats a lot of reporting and redistribution work (and would leave
them more time for research). Thank you.
-- Tom.
∂20-Dec-88 1544 @Score.Stanford.EDU:goldberg@polya.Stanford.EDU Ph.D. research
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Dec 88 15:44:44 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 20 Dec 88 15:42:29-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA01620; Tue, 20 Dec 88 15:43:07 PDT
Date: Tue 20 Dec 88 15:43:05-PST
From: Andrew V. Goldberg <GOLDBERG@Polya.Stanford.EDU>
Subject: Ph.D. research
To: faculty@score
Message-Id: <598664585.0.GOLDBERG@Polya.Stanford.EDU>
Mail-System-Version: <VAX-MM(229)+TOPSLIB(128)@Polya.Stanford.EDU>
I'd like to add some points to the discussion.
I think the biggest problem is that of attitude: students are being told
to start research earlier, but comps provide an excuse not to do this.
A Berkeley -- where in fact a significant fraction of students is kicked
out because of the exams -- there still is a tendency to start research
right away. This is partially explained by a semi-formal practice to
relax the breadth requirenments for students doing good research.
Sometimes this has bad effects -- some smart students get away with
graduating without learning some of the fundamentals of CS, but otherwise
the system seems to work.
I think the faculty should have an option of reviewing individual student
cases, considering both comp performance and research, and deciding on
that information.
I'd also like to mention that working with other students is very valuable,
but it cannot replace working with a good advisor (at least in the area of
theory).
--Andy
-------
∂20-Dec-88 1816 @polya.Stanford.EDU:tah@linz Minimal models
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Dec 88 18:16:21 PST
Received: from linz.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA08107; Tue, 20 Dec 88 18:14:31 PDT
Received: by linz.stanford.edu (5.59/25-eef) id AA06067; Tue, 20 Dec 88 18:10:48 PDT
Message-Id: <8812210210.AA06067@linz.stanford.edu>
To: lop@polya
Cc: shoham@polya
Subject: Minimal models
Reply-To: tah@cs.stanford.edu
Date: 20 Dec 88 18:10:44 PST (Tue)
From: Tom Henzinger <tah@linz>
We've been discussing initial and final algebras as "distinguished"
models for equational/Horn theories. Now there are several other
approaches in logic/CS to somehow restrict the number of "classical"
models, in order to allow a (more concise) syntactic characterization
of a certain (class of) structure(s).
Immediately to mind come:
+ Logic programming. Restriction to "least" Herbrand models.
+ Circumscription. Restriction to "minimal" models.
+ Conditional logics. Nonmonotonic, nontransitive consequence relations.
(M |= A->B iff N|=B for the "minimal revision" N of M such that N|=A.)
+ Model theory (so Tim tells me). Prime and saturated models.
So what is the connection between all these approaches to, in some
sense, "minimal" modeling? Do, for example, all of them incorporate
the power of some second-order induction-like axiom into a redefinition
of classical (first-order) semantics? Is this an interesting question?
-- Tom.
∂20-Dec-88 2226 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Complete axiom sets for arithmetic equations,
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Dec 88 22:26:33 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA11263; Tue, 20 Dec 88 22:26:05 PDT
Message-Id: <8812210626.AA11263@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 20 Dec 88 22:26:29 PST
Received: by BYUADMIN (Mailer R2.01A) id 6615; Tue, 20 Dec 88 23:24:32 MST
Date: Tue, 20 Dec 88 23:16:37 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Undetermined origin c/o Postmaster <POSTMASTER%NDSUVM1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: <Parser> E: Unmatched parenthesis in address field.
From: Undetermined origin c/o Postmaster <POSTMASTER%NDSUVM1.BITNET@forsythe.stanford.edu>
Subject: Complete axiom sets for arithmetic equations,
using only equational rea
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
I am working with equational axioms for Peano arithmetic, but I wonder
whether I have a complete set. I don't want to do induction proofs, just
equational reasoning, so the question is whether a finite set of
axioms can express all true arithmetic equations.
I am especially interested in equations where addition, multiplication,
exponentiation and variables may occur, but not constants.
Thus:
expr ::= expr + expr
| expr * expr
| expr ~ expr
| variable
equation ::= expr = expr
Question 1) Is the following set of axioms complete? That is, can all
equations that are provable in Peano arithmetic be derived from
the axioms using only equational reasoning?
x+y = y+x (1)
x+(y+z) = (x+y)+z (2)
x*y = y*x (3)
x*(y*z) = (x*y)*z (4)
x*(y+z) = x*y + x*z (5)
x~(y+z) = x~y * x~z (6)
(x~y)~z = x~(y*z) (7)
(x*y)~z = x~z * y~z (8)
Question 2) Suppose that we also allow the constants 0 and 1 as expressions.
Is it then enough to add these axioms?
x+0 = x (9)
x*0 = 0 (10)
x~0 = 1 (11)
x*1 = x (12)
x~1 = x (13)
1~x = 1 (14)
Question 3) Suppose that we disallow '+' in expressions. Do we then get
a complete axiom system if we delete those axioms
where '+' occurs?
(This question can be asked both for the variant with constants,
and the one without.)
If the answer is 'no' to any of these questions, I would of course
want to know whether I have simply forgotten some axioms, or if it is
impossible to give a finite equational axiomatisation.
Any kind of information about these problems will be gratefully received.
Mikael Rittri
E-mail: rittri@cs.chalmers.se
Dept. of Computer Sciences
Chalmers Univ. of Technology
S-412 96 Goteborg, Sweden
∂20-Dec-88 2301 @Score.Stanford.EDU:linton@interviews.stanford.edu Re: Ph.D. research
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Dec 88 23:01:48 PST
Received: from interviews.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 20 Dec 88 22:59:58-PST
Received: by interviews.stanford.edu (5.57/Ultrix2.4-C)
id AA11656; Tue, 20 Dec 88 22:58:45 PST
Date: Tue, 20 Dec 88 22:58:45 PST
From: linton@interviews.stanford.edu (Mark Linton)
Message-Id: <8812210658.AA11656@interviews.stanford.edu>
To: faculty@score.stanford.edu
Subject: Re: Ph.D. research
I suppose comp-bashing is easy because the comps can't fight back,
but I can't believe they are the cause of the problem. Berkeley
students must take 2-3 years of course work (at least they did 5 years ago),
which is a much greater distraction than studying for comps.
Stanford EE also requires this amount of course work.
Mark
∂21-Dec-88 0910 @Score.Stanford.EDU:daniel@mojave.Stanford.EDU Ph.D. research: the difference between exam requirements and course requirements.
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Dec 88 09:10:05 PST
Received: from mojave.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 21 Dec 88 09:07:44-PST
Received: by mojave.Stanford.EDU (5.59/inc-1.0)
id AA10440; Wed, 21 Dec 88 09:08:47 PDT
Date: Wed, 21 Dec 88 09:08:47 PDT
From: daniel@mojave.Stanford.EDU (Daniel Weise)
Message-Id: <8812211708.AA10440@mojave.Stanford.EDU>
To: linton@lurch.stanford.edu
Cc: faculty@score.stanford.edu
Subject: Ph.D. research: the difference between exam requirements and course requirements.
The difference between courses and exams is that students view courses
as knowns: they know how little or how much work to do to satisfy a
course requirement. This is not so for noncourse-related exams. More
studying is always necessary because one doesn't know what part of the
massive reading list will be tested. It's the paranoia factor we
have to address.
Like inflation, exam paranoia is a self-sustaining and growing
problem. MIT CS stopped their comprehensive written exams just a few
years after instituting them because each year students spent more and
more time studying for them.
I believe our students should have a comprehensive background, but
that the way we go about ensuring this is wrong. First, we should
eliminate some of the areas we require, such as graphics and networks.
Second, we should be willing to take as evidence of background
undergraduate and graduate courses the students have had. If a
student hasn't had a course in an area we require then they must
either take a test or a course in that specific area.
The advantage of this approach is that the students will see
fulfilling the requirement as covering a hole in their background
rather as than jumping through a hoop. They will view the time taken
for meeting the requirement as fruitfully spent. Students who
matriculate fully prepared will be able to start research immediately.
Students who need to take a few courses will be able to simultaneously
take courses and do research. The paranoia factor will be eliminated.
Daniel
∂21-Dec-88 0913 aaai@sumex-aim.stanford.edu Happy Holidays!
Received: from sumex-aim.stanford.edu by SAIL.Stanford.EDU with TCP; 21 Dec 88 09:12:50 PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA11296; Wed, 21 Dec 88 09:05:39 PST
Date: Wed, 21 Dec 1988 9:05:37 PST
From: AAAI <aaai@sumex-aim.stanford.edu>
To: officers:;@sumex-aim.stanford.edu
Cc: aaai@sumex-aim.stanford.edu
Subject: Happy Holidays!
Message-Id: <CMM.0.88.598727137.aaai@sumex-aim.stanford.edu>
The AAAI staff would like to wish the officers and councilors Happy
Holidays and Merry Christmas!
Cheers,
Claudia
∂21-Dec-88 0946 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU comprehensives and research orientation
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Dec 88 09:45:11 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 21 Dec 88 09:43:05-PST
Message-ID: <8TXSs@SAIL.Stanford.EDU>
Date: 21 Dec 88 0943 PST
From: John McCarthy <JMC@SAIL.Stanford.EDU>
Subject: comprehensives and research orientation
To: faculty@SCORE.Stanford.EDU
I have been here for 26 years and witnessed many perturbations in
the examination process. None of the approximately 10 reforms
have seemed to me really well motivated. Most of them come from
two sources. First some students find some aspect of the exams
too hard. Second faculty (and students who have been through
the exams) want to put new topics on the exams. In the AI qual
this resulted in a reading list so enormous that I once walked
out at the beginning of an oral on the grounds that I could
not honestly examine students who were supposed to have prepared
on the basis of a bibliography of which I had read such a small
proportion. I don't know if there is any AI at all on the
comprehensive now. If there is, I would propose to remove it
on the grounds that AI is better taught in connection with
research than by preparing for an exam. I want to keep
mathematical logic on the comprehensive as a foundation for AI
research. I also believe that the basic mathematics of program
verification should be kept.
∂21-Dec-88 0946 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: Linear Programming Program Needed
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Dec 88 09:44:44 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA17370; Wed, 21 Dec 88 09:44:18 PDT
Message-Id: <8812211744.AA17370@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Wed, 21 Dec 88 09:44:42 PST
Received: by BYUADMIN (Mailer R2.01A) id 4370; Wed, 21 Dec 88 10:43:02 MST
Date: Wed, 21 Dec 88 11:36:45 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Steve Vestal Steve Vestal <vestal@ALTURA.SRC.HONEYWELL.COM>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Steve Vestal Steve Vestal <vestal@ALTURA.SRC.HONEYWELL.COM>
Subject: Re: Linear Programming Program Needed
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
I've got a PC LP package if you're interested (Unix, too). The fixed
limitation is that the number of variables + the number of constraints doesn't
exceed 3600 (PC) or 16000 (Unix). It uses a sparse matrix representation,
and the operational limit is that all the non-zero coefficients fit in
your memory. It's a primal/dual algorithm, so it doesn't really matter
whether you're lopsided towards variables or constraints. The real strength
of the package is it's high-level matrix generation language: subscripted
variables, read/write statements (including spreadsheet files),
conditionals, etc. Makes it easy to play around different models.
Steve Vestal, (612) 490-0356 evenings
∂21-Dec-88 1013 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: Complete axiom sets for arithmetic equations
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Dec 88 10:13:13 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA18216; Wed, 21 Dec 88 10:12:50 PDT
Message-Id: <8812211812.AA18216@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Wed, 21 Dec 88 10:13:13 PST
Received: by BYUADMIN (Mailer R2.01A) id 4596; Wed, 21 Dec 88 11:06:17 MST
Date: Wed, 21 Dec 88 11:38:16 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Stephen J. Garland" <garland%LARCH.LCS.MIT.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Stephen J. Garland" <garland%LARCH.LCS.MIT.EDU@Forsythe.Stanford.EDU>
Subject: Re: Complete axiom sets for arithmetic equations
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Mikael Rittri of the Chalmers Univ. of Technology is Goteborg, Sweden,
asks whether various equational axiomatizations for Peano arithmetic are
equationally complete. Answers to his questions, insofar as they were known
in 1977, can be found in ``The Logic of Equality'' by Leon Henkin, American
Mathematical Monthly 84 (1977), pp. 597-612. Rittri's questions, with Henkin's
answers, follow.
Question 1) Is the following set of axioms complete? That is, can all
equations that are provable in Peano arithmetic be derived from
the axioms using only equational reasoning?
x+y = y+x (1)
x+(y+z) = (x+y)+z (2)
x*y = y*x (3)
x*(y*z) = (x*y)*z (4)
x*(y+z) = x*y + x*z (5)
x~(y+z) = x~y * x~z (6)
(x~y)~z = x~(y*z) (7)
(x*y)~z = x~z * y~z (8)
Henkin cites a 1973 Ph. D. thesis by Charles Martin, a student of
Tarski's, in which it is shown that no finite set of axioms suffices. In
particular, Martin shows that the identity
(x~y + x~y)~x * (y~x + y~x)~y = (x~x + x~x)~y * (y~y + y~y)~x
is not derivable from axioms (1) through (8).
Question 2) Suppose that we also allow the constants 0 and 1 as expressions.
Is it then enough to add these axioms?
x+0 = x (9)
x*0 = 0 (10)
x~0 = 1 (11)
x*1 = x (12)
x~1 = x (13)
1~x = 1 (14)
Henkin attributes this question to Tarski and says the answer is unknown.
Question 3) Suppose that we disallow '+' in expressions. Do we then get a
complete axiom system if we delete those axioms where '+' occurs?
Martin shows that the answer is "yes" in the case without constants.
Stephen J. Garland
MIT Laboratory for Computer Science
garland@lcs.mit.edu
∂21-Dec-88 1328 SLOAN@Score.Stanford.EDU Closing of offices tomorrow
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Dec 88 13:28:40 PST
Date: Wed 21 Dec 88 13:16:14-PST
From: Yvette Sloan <SLOAN@Score.Stanford.EDU>
Subject: Closing of offices tomorrow
To: csd-list@Score.Stanford.EDU, csd@Score.Stanford.EDU
Message-ID: <12456266635.23.SLOAN@Score.Stanford.EDU>
Departmental offices will close at 3:00 p.m. tomorrow (December 22) so that
we may start our Christmas holiday. Tomorrow is PAYDAY. If you need to
pick up your paycheck, plan to do so before 3:00 p.m.
Merry Christmas!!
--Yvette
-------
∂21-Dec-88 1347 @Score.Stanford.EDU:pratt@chehalis.stanford.edu status of "cs.stanford.edu"
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Dec 88 13:45:03 PST
Received: from chehalis.stanford.edu by SCORE.STANFORD.EDU with TCP; Wed 21 Dec 88 13:43:05-PST
Received: by chehalis.stanford.edu (5.59/25-eef) id AA00755; Wed, 21 Dec 88 13:43:14 PDT
Date: Wed, 21 Dec 88 13:43:14 PDT
From: Vaughan Pratt <pratt@chehalis.stanford.edu>
Message-Id: <8812212143.AA00755@chehalis.stanford.edu>
To: faculty@score
Subject: status of "cs.stanford.edu"
It would be *very* nice if (at least) those of us on the CS faculty and
staff could be mailed to as surname@cs.stanford.edu. Currently cs is a
synonym for polya, which presumably implements just this. However I
haven't seen this synonym advertised anywhere, so before I start
telling everyone that that's my new address I'd like to find out its
status.
Is there anything resembling a policy on the care and feeding of this
name? Can we assume that the department owns the name and intends to
keep it in working order (e.g. by switching it to another machine
temporarily if polya is so unfortunate as to be down for several days)?
-v
∂21-Dec-88 1351 @Score.Stanford.EDU:RWF@SAIL.Stanford.EDU re: Ph.D. research: the difference between exam requirements and course requirements.
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Dec 88 13:51:22 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 21 Dec 88 13:49:23-PST
Message-ID: <14Tx8$@SAIL.Stanford.EDU>
Date: 21 Dec 88 1348 PST
From: Robert W Floyd <RWF@SAIL.Stanford.EDU>
Subject: re: Ph.D. research: the difference between exam requirements and course requirements.
To: daniel@MOJAVE.STANFORD.EDU, linton@LURCH.STANFORD.EDU
CC: faculty@SCORE.Stanford.EDU
[In reply to message from daniel@mojave.Stanford.EDU sent Wed, 21 Dec 88 09:08:47 PDT.]
I am skeptical about accepting undergrad courses as evidence of breadth.
For one thing, I regularly ask incoming students questions like:
Have you had a course in modern algebra? (answer yes or i think so)
Define an ideal. (ans i don't remember but i could look it up)
Prove that the order of a group element divides the order of the group.
(ans: mumble). Same thing for statistics, computability theory,
NP completeness, etc.
For another thing, most undergrads at good schools I've sampled,
say Berkeley, Cornell, and Stanford, are taking watered-down
touchy-feely versions of some courses. A student who gets a PhD
knowing what the students learn in CS154 is not ready to step in
and teach it on short notice, still less to teach a rigorous
course. I think a PhD should be able to teach any intro level
core CS course. Remember what DOCTOR means in Latin (it doesn't
mean researcher).
∂21-Dec-88 1605 @Score.Stanford.EDU:pratt@chehalis Re: Ph.D. research: the difference between exam requirements and course requirements.
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Dec 88 16:05:33 PST
Received: from chehalis.stanford.edu by SCORE.STANFORD.EDU with TCP; Wed 21 Dec 88 15:58:56-PST
Received: by chehalis.stanford.edu (5.59/25-eef) id AA00943; Wed, 21 Dec 88 15:58:46 PDT
Message-Id: <8812212358.AA00943@chehalis.stanford.edu>
To: Robert W Floyd <RWF@sail.stanford.edu>
Cc: faculty@score.stanford.edu
Subject: Re: Ph.D. research: the difference between exam requirements and course requirements.
In-Reply-To: Your message of 21 Dec 88 1348 PST.
<14Tx8$@SAIL.Stanford.EDU>
Date: 21 Dec 88 15:58:40 PST (Wed)
From: pratt@chehalis
Define an ideal. (ans i don't remember but i could look it up)
By chance Bob picked my favorite example of something you *can't*
find the definition of by looking it up. Different texts define
"ideal" specialized to the class of structures at hand. What do you
want an ideal of? Posets? A downward-closed subset (= an order
ideal). Semilattices? An order ideal closed under join. Lattices? A
prime semilattice ideal. Rings? A subset closed under addition of
ideal elements and multiplication by ring elements.
The "right" answer, which I don't believe can be looked up in any
algebra book (counterexamples gratefully received) is that an ideal is
an inverse image of 0.
With that answer one gets additional insight into ideals. For example
an ideal of a group is more commonly known as a normal subgroup, while
a monoid ideal of a group is just a subgroup.
Details on request.
-v
∂21-Dec-88 1722 @Score.Stanford.EDU:RWF@SAIL.Stanford.EDU re: Ph.D. research: the difference between exam requirements and course requirements.
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Dec 88 17:22:47 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 21 Dec 88 17:20:48-PST
Message-ID: <4T#vC@SAIL.Stanford.EDU>
Date: 21 Dec 88 1721 PST
From: Robert W Floyd <RWF@SAIL.Stanford.EDU>
Subject: re: Ph.D. research: the difference between exam requirements and course requirements.
To: pratt@CHEHALIS.Stanford.EDU, RWF@SAIL.Stanford.EDU
CC: faculty@SCORE.Stanford.EDU
[In reply to message from pratt@chehalis sent 21 Dec 88 15:58:40 PST.]
All right, Vaughan, we will waive the comp requirement
in your case, but I won't hold my breath until an
incoming student gives me such a good answer.
∂21-Dec-88 1930 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Complete axiom sets for arithmetic equations,
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Dec 88 19:30:01 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA02297; Wed, 21 Dec 88 19:29:38 PDT
Message-Id: <8812220329.AA02297@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Wed, 21 Dec 88 19:30:02 PST
Received: by BYUADMIN (Mailer R2.01A) id 4828; Wed, 21 Dec 88 19:44:10 MST
Date: Wed, 21 Dec 88 14:58:25 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Mikael Rittri <rittri%CS.CHALMERS.SE@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Mikael Rittri <rittri%CS.CHALMERS.SE@Forsythe.Stanford.EDU>
Subject: Complete axiom sets for arithmetic equations,
using only equational rea
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
I am working with equational axioms for Peano arithmetic, but I wonder
whether I have a complete set. I don't want to do induction proofs, just
equational reasoning, so the question is whether a finite set of
axioms can express all true arithmetic equations.
I am especially interested in equations where addition, multiplication,
exponentiation and variables may occur, but not constants.
Thus:
expr ::= expr + expr
| expr * expr
| expr ~ expr
| variable
equation ::= expr = expr
Question 1) Is the following set of axioms complete? That is, can all
equations that are provable in Peano arithmetic be derived from
the axioms using only equational reasoning?
x+y = y+x (1)
x+(y+z) = (x+y)+z (2)
x*y = y*x (3)
x*(y*z) = (x*y)*z (4)
x*(y+z) = x*y + x*z (5)
x~(y+z) = x~y * x~z (6)
(x~y)~z = x~(y*z) (7)
(x*y)~z = x~z * y~z (8)
Question 2) Suppose that we also allow the constants 0 and 1 as expressions.
Is it then enough to add these axioms?
x+0 = x (9)
x*0 = 0 (10)
x~0 = 1 (11)
x*1 = x (12)
x~1 = x (13)
1~x = 1 (14)
Question 3) Suppose that we disallow '+' in expressions. Do we then get
a complete axiom system if we delete those axioms
where '+' occurs?
(This question can be asked both for the variant with constants,
and the one without.)
If the answer is 'no' to any of these questions, I would of course
want to know whether I have simply forgotten some axioms, or if it is
impossible to give a finite equational axiomatisation.
Any kind of information about these problems will be gratefully received.
Mikael Rittri
E-mail: rittri@cs.chalmers.se
Dept. of Computer Sciences
Chalmers Univ. of Technology
S-412 96 Goteborg, Sweden
∂21-Dec-88 1935 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Complete axiom sets for arithmetic equations
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Dec 88 19:34:54 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA02340; Wed, 21 Dec 88 19:34:37 PDT
Message-Id: <8812220334.AA02340@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Wed, 21 Dec 88 19:35:01 PST
Received: by BYUADMIN (Mailer R2.01A) id 6539; Wed, 21 Dec 88 20:32:52 MST
Date: Wed, 21 Dec 88 21:27:45 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
meyer%THEORY.LCS.MIT.EDU@Forsythe.Stanford.EDU
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: meyer%THEORY.LCS.MIT.EDU@Forsythe.Stanford.EDU
Subject: Complete axiom sets for arithmetic equations
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Comment on Garland's comment:
Henkin's article was about axiomatizing the equations VALID in arithmetic,
not just those PROVABLE from the Peano axioms. I'm not aware that these are
known to be the same: is Peano complete for this subset of formulas?
Yours truly,
Prof. Albert R. Meyer
MIT Lab. for Computer Science
∂22-Dec-88 0925 @Score.Stanford.EDU:RPG@SAIL.Stanford.EDU Students and Research
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Dec 88 09:25:40 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 22 Dec 88 09:23:40-PST
Message-ID: <DU8vB@SAIL.Stanford.EDU>
Date: 22 Dec 88 0923 PST
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Subject: Students and Research
To: faculty@SCORE.Stanford.EDU
The debate on PhD requirements started as a debate about how to get
students to get into research and be better researchers. I'm afraid
(but I don't know) that Stanford's problem is deeper than the comp
requirements stalling people.
The students I know these days don't seem to have the same
fire-in-the-belly that I remember from the mid-70's through the mid-80's.
By this I don't mean that they are less intelligent, but that they
seem less interested in quickly making their marks in research.
I have three theories about this:
1. The students we got 15 years ago were often not from computer science
backgrounds, and usually they had math backgrounds. I'm not sure that the
math background was the important thing except that folks with math
backgrounds like me learned a rigorous way of thinking (no comments
please) but no body of important information. Therefore, such students are
in the right frame of mind to absorb CS quickly and are in a position to
think out their research problems. Today CS students have learned CS at
a stage of their lives when what they learn is rigid and sacred, which is
not a good attitude with which to approach research.
2. When I learned CS, we used math books and quasi math books (Knuth Vol
1) for what we needed to do analysis, and we used research papers and
journal articles to learn CS. When you learn CS with CS books, you're not
getting the feel of the science as it lives, but as it is now viewed. So
the role models we had back then were working researchers with current
papers, and the ones students have now are working scholars and
academicians with books on worked-over material. The glamor of research is
squeezing off a series of hot papers, not writing a thoughtful textbook
(apologies to Jeff Ullman).
And we worked to imitate these hotshots: we'd know the deadlines for conferencs
and we'd try to meet those deadlines with our own papers, and we'd get help
and criticism from our peers and advisors. When the conference was over, we'd
get a group together to read the papers and present them to each other.
3. Stanford used to be a ``big science'' school in CS. That is, when I was
choosing grad schools, Stanford had big AI projects, and I was attracted
to them. There were lots of big projects with about a dozen researchers
we wanted to imitate and work with. With a big project you have the
ability to join and get work done while remaining behind the scenes until
you feel you are up to speed and ready to try your stuff. There was a
range of grad students to illustrate the stages of development you had to
go through. And the project was one that would make a big difference to
the course of CS and would make you famous.
Whether or not Stanford has any such project today, it doesn't seem like
it does. Having spent some time trying to entice people I knew and worked
with to Stanford to be grad students, I found that these guys wanted to go
to MIT, for example, to ``work with the <mumble> project.'' They told me
that Stanford didn't have any projects they wanted to join.
I happen to think that big projects can provide the localized critical
mass of enthusiasm you need to attract and nurture students. I believe MIT
and probably CMU still have this setup, and I think we fail to attract
students who will be good researchers - they go elsewhere. Therefore, no
amount of tweaking the system will fix it. The problem is that Stanford
CS is dull and attracts research-dull students.
4. It might be that CS has now progressed to the point where it is not possible
to do big science (and I don't mean hacking projects), and therefore we are
inherently screwed, but MIT seems to still do it. However, I think we ought to
try to at least bring back the practice of trying to get students to write
research papers.
Here is a sad story: I employ a CS PhD student at Lucid. This student has
a good advisor. We write a lot of research papers together. We worked on
the design and specification of an important system together. The student
says that the advisor ``never taught how to write papers,'' but that I
did. This is fine because I'm affiliated with Stanford, but it is not fine
because I am not the advisor.
-rpg-
∂22-Dec-88 1028 @Score.Stanford.EDU:gio@sumex-aim.stanford.edu Re: comprehensives and research orientation
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Dec 88 10:28:01 PST
Received: from sumex-aim.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 22 Dec 88 10:14:46-PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA23918; Thu, 22 Dec 88 10:14:08 PST
Date: Thu, 22 Dec 1988 10:14:07 PST
From: Gio Wiederhold <gio@sumex-aim.stanford.edu>
To: John McCarthy <JMC@sail.stanford.edu>
Cc: faculty@score.stanford.edu
Subject: Re: comprehensives and research orientation
In-Reply-To: Your message of 21 Dec 88 0943 PST
Message-Id: <CMM.0.88.598817647.gio@sumex-aim.stanford.edu>
There is AI theory in the theory section, probably corresponding to what you
would like as foundation, and some pragmatics in the Application section.
I would like to retain that much AI in the comprehensive, not for the sake of
research --- here the qual is the barrier, but for the sake of general
education. I'd hate to have database specializing students who don't even
have the minimal comprehension of AI that we ask now as part of the comp.
Gio
∂22-Dec-88 1049 @Score.Stanford.EDU:winograd@loire.stanford.edu Re: research
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Dec 88 10:48:39 PST
Received: from loire.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 22 Dec 88 10:45:29-PST
Received: by loire.stanford.edu (5.59/25-eef) id AA18475; Thu, 22 Dec 88 10:45:11 PDT
Date: Thu, 22 Dec 88 10:45:11 PDT
Message-Id: <8812221845.AA18475@loire.stanford.edu>
From: Winograd@csli.stanford.edu
To: faculty@score, phd@score
Subject: Re: research
Dick Gabriel's note compared our research environment unfavorably with
MIT. You may be interested in a document called "How to do research at the
AI Lab", issued as MIT AI Working paper 316, October 1988, wlritten by
"a whole bunch of current, former, and honorary MIT AI Lab graduate
students." It is 36 pages long and discusses a wide variety of topics,
including "Getting connected", "Learning other fields", "Advisors",
"Research Methodology", "Emotional factors," etc. I haven't read it
through, but on a quick scan it looks sensible and useful. I can make
my copy available for copying. --t
p.s., as a side note, it singles out the Stanford AI reading list that
John McCarthy objected to as being particuarly useful.
∂22-Dec-88 1139 X3J13-mailer Error terminology
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 22 Dec 88 11:39:15 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04427g; Wed, 21 Dec 88 22:05:23 PST
Received: by bhopal id AA10159g; Wed, 21 Dec 88 22:06:00 PST
Date: Wed, 21 Dec 88 22:06:00 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812220606.AA10159@bhopal>
To: chapman%aitg.DEC@decwrl.dec.com
Cc: x3j13@sail.stanford.edu
In-Reply-To: chapman%aitg.DEC@decwrl.dec.com's message of 3 Oct 88 15:42 <8810031951.AA06841@decwrl.dec.com>
Subject: Error terminology
re: - THE "CONSEQUENCES ARE UNSPECIFIED"
means that
. . .
- ... and all portable programs are required to treat
the situation as unpredictable but harmless.
It looks like to me that "harmless" has the same lack of specificity
as Barry's word "benign". Taken in context of the rest of your message,
it could only mean "not fatal". Is that good enough?
[By the bye, was this msg really intended for x3j13 distribution? or
should it have been cl-editorial?]
-- JonL --
∂22-Dec-88 1147 TAJNAI@Score.Stanford.EDU Sunrise Club, Jan. 17.
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Dec 88 11:47:35 PST
Date: Thu 22 Dec 88 11:41:33-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Sunrise Club, Jan. 17.
To: faculty@Score.Stanford.EDU, PHD@Score.Stanford.EDU, RAS@Score.Stanford.EDU
cc: hiller@Score.Stanford.EDU
Message-ID: <12456511542.16.TAJNAI@Score.Stanford.EDU>
TO: Faculty, Research Associates and PHD students
FROM: Carolyn Tajnai
RE: Sunrise Meeting, Jan. 17, 1988
The next Sunrise Club meeting will be on Tuesday,
January 17, 1989, same place, same time - Tresidder
Union, Oak Lounge West at 7:30 a.m. The speaker
will be Dr. R. Fabian Pease of the Electrical
Engineering Department whose lecture is titled
"The Impact of Micro-miniaturization on Electronics."
Please R.S.V.P. to Bonnie Hiller (3-3051) or Hiller@Score.
-------
∂22-Dec-88 1241 X3J13-mailer Re: Corrections to the ISO Report
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 22 Dec 88 12:35:20 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa06698; 22 Dec 88 20:30 GMT
Date: Thu, 22 Dec 88 20:27:12 GMT
Message-Id: <20454.8812222027@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Corrections to the ISO Report
To: rpg <@sail.stanford.edu:rpg@lucid.com>, x3j13@sail.stanford.edu
In-Reply-To: Richard P. Gabriel's message of Mon, 19 Dec 88 22:35:13 PST
> 2. There was a wording problem with my comments on the AFNOR
> delegation's response to the US position.
I think there are two issues. One is that the NWI does not talk
about multiple standards for multiple varieties ("dialects" might
be prejudicial) of Lisp. At the first WG-16 meeting in Paris,
the US made the point that an ISO standard named something like
"ISO Lisp" might seem to preclude standards for other varieties
of Lisp but there was not, as far as I can recall (I haven't checked
my notes), anything said about multiple standards under the current
Work Item. The US seemed willing then to have WG-16 work on a
single standard, even one based on Common Lisp. Indeed, the US
insisted that the WG-16 schedule (the 18 months) required a starting
point in existing work, and the US voted for "Common Lisp or Scheme"
as the starting point.
This brings us to the second issue, for which you have found the
convenient term "work plan". I think the following is a fair
summary:
1. At the first WG-16, the US cooperated in drafting the work
plan and did not voice strong objections. We can contrast
this with the US approach to the name of the standard, where
the US made it clear that "ISO Lisp" was unacceptable.
However, the US made the point that any deviation from
CL would need an environmental impact statement.
2. At the second WG-16, the US was unhappy with some of the defaults
and preferred that changes be deletions (so that the ISO standard
would be a strict rather than "extended" subset). It was
explained, by the Convenor and others, that the default values
would not be adopted just because they were the defaults. The
US seemed to accept this explanation.
3. Before the third WG-16, the US distributed a position statement
which, in effect, said that the US would oppose any changes to
Common Lisp that were not deletions. This was a hardening of
what seemed to be the US position in the second meeting, because
changes would be opposed simply because they were not deletions,
regardless of technical or practical merit. (Of course,
deletions might still be opposed on those grounds, and such
reasons might be given as additional reasons for opposing
non-deletions.)
So, it appears to me that the US position has changed. Whether it
is a "preposterous" change is less clear. It might be argued that
the position has evolved. Nonetheless,
> The US did not agree to this work plan, and the evidence for this
> is simply that the acceptability of the work plan never came to a
> vote at WG16. Therefore, the US did not change its position regarding
> this work plan, and the current US position is the first time the US
> took any position with regard to the work plan for WG16 proposed by the
> AFNOR delegation.
It can be argued that the US has officially said only three things.
One is the comment on the NWI stating opposition to the name "ISO
Lisp". Another is the position statement distributed before the
3rd WG-16. Then, finally, there's the proposal for an ISO Common
Lisp standard presented at the 3rd meeting. Indeed, it might be
argued that only the first is really official, because only it
involved a vote in X3J13 (if even that is enough). However, if
we're to take a "letter of the law" approach, it must be noted that
a change from no official position to official opposition is still
a change.
There is one additional point I would like to make. Although the
initial list of issues and defaults, and the idea that we should
proceed in this way, came from AFNOR, the final list was the result
of comments by other countries, including the US. Moreover, there
appeared to be a consensus (that included the US) on the following
statement:
The draft standard to be provided by the Working Group within
18 months will take as starting point Common Lisp (with X3J13
cleanups) with treatment of major issues and default values
to be identified (including issues in the AFNOR list and on
agenda).
> When the AFNOR delegation stated that the US position represented a
> ``preposterous'' change in position by the US, I interpreted their
> statement as a response to an incorrectly perceived change in position
> by the US regarding the never-agreed-on AFNOR-proposed work plan. The
> only alternative interpretation I could think of is that the AFNOR
> delegation incorrectly perceived a change in position by the US to the
> New Work Item that defines the goal of WG16. Since the latter
> interpretation is illogical, I adopted the other one.
I think you were right to adopt the other one.
Jeff Dalton, JANET: J.Dalton@uk.ac.ed
AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
∂22-Dec-88 1356 @Score.Stanford.EDU:eaf@sumex-aim.stanford.edu Re: comprehensives and research orientation
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Dec 88 13:56:34 PST
Received: from sumex-aim.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 22 Dec 88 13:54:16-PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA28109; Thu, 22 Dec 88 13:53:39 PST
Date: Thu, 22 Dec 1988 13:53:39 PST
From: Edward A. Feigenbaum <eaf@sumex-aim.stanford.edu>
To: John McCarthy <JMC@sail.stanford.edu>
Cc: faculty@score.stanford.edu
Subject: Re: comprehensives and research orientation
In-Reply-To: Your message of 21 Dec 88 0943 PST
Message-Id: <CMM.0.88.598830819.eaf@sumex-aim.stanford.edu>
Although it was a little painful to both prepare and grade questions on
the AI section of the comprehensive, I agree with Gio (and therefore
disagree with John) that a general education in CS requires some
knowledge of AI (even if it turns out to be, for purposes of the
comprehensive, only "a meter wide but a millimeter thick").
Ed F.
∂22-Dec-88 1447 X3J13-mailer Re: Corrections to the ISO Report
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 22 Dec 88 14:45:02 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa06698; 22 Dec 88 20:30 GMT
Date: Thu, 22 Dec 88 20:27:12 GMT
Message-Id: <20454.8812222027@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Corrections to the ISO Report
To: rpg <@sail.stanford.edu:rpg@lucid.com>, x3j13@sail.stanford.edu
In-Reply-To: Richard P. Gabriel's message of Mon, 19 Dec 88 22:35:13 PST
> 2. There was a wording problem with my comments on the AFNOR
> delegation's response to the US position.
I think there are two issues. One is that the NWI does not talk
about multiple standards for multiple varieties ("dialects" might
be prejudicial) of Lisp. At the first WG-16 meeting in Paris,
the US made the point that an ISO standard named something like
"ISO Lisp" might seem to preclude standards for other varieties
of Lisp but there was not, as far as I can recall (I haven't checked
my notes), anything said about multiple standards under the current
Work Item. The US seemed willing then to have WG-16 work on a
single standard, even one based on Common Lisp. Indeed, the US
insisted that the WG-16 schedule (the 18 months) required a starting
point in existing work, and the US voted for "Common Lisp or Scheme"
as the starting point.
This brings us to the second issue, for which you have found the
convenient term "work plan". I think the following is a fair
summary:
1. At the first WG-16, the US cooperated in drafting the work
plan and did not voice strong objections. We can contrast
this with the US approach to the name of the standard, where
the US made it clear that "ISO Lisp" was unacceptable.
However, the US made the point that any deviation from
CL would need an environmental impact statement.
2. At the second WG-16, the US was unhappy with some of the defaults
and preferred that changes be deletions (so that the ISO standard
would be a strict rather than "extended" subset). It was
explained, by the Convenor and others, that the default values
would not be adopted just because they were the defaults. The
US seemed to accept this explanation.
3. Before the third WG-16, the US distributed a position statement
which, in effect, said that the US would oppose any changes to
Common Lisp that were not deletions. This was a hardening of
what seemed to be the US position in the second meeting, because
changes would be opposed simply because they were not deletions,
regardless of technical or practical merit. (Of course,
deletions might still be opposed on those grounds, and such
reasons might be given as additional reasons for opposing
non-deletions.)
So, it appears to me that the US position has changed. Whether it
is a "preposterous" change is less clear. It might be argued that
the position has evolved. Nonetheless,
> The US did not agree to this work plan, and the evidence for this
> is simply that the acceptability of the work plan never came to a
> vote at WG16. Therefore, the US did not change its position regarding
> this work plan, and the current US position is the first time the US
> took any position with regard to the work plan for WG16 proposed by the
> AFNOR delegation.
It can be argued that the US has officially said only three things.
One is the comment on the NWI stating opposition to the name "ISO
Lisp". Another is the position statement distributed before the
3rd WG-16. Then, finally, there's the proposal for an ISO Common
Lisp standard presented at the 3rd meeting. Indeed, it might be
argued that only the first is really official, because only it
involved a vote in X3J13 (if even that is enough). However, if
we're to take a "letter of the law" approach, it must be noted that
a change from no official position to official opposition is still
a change.
There is one additional point I would like to make. Although the
initial list of issues and defaults, and the idea that we should
proceed in this way, came from AFNOR, the final list was the result
of comments by other countries, including the US. Moreover, there
appeared to be a consensus (that included the US) on the following
statement:
The draft standard to be provided by the Working Group within
18 months will take as starting point Common Lisp (with X3J13
cleanups) with treatment of major issues and default values
to be identified (including issues in the AFNOR list and on
agenda).
> When the AFNOR delegation stated that the US position represented a
> ``preposterous'' change in position by the US, I interpreted their
> statement as a response to an incorrectly perceived change in position
> by the US regarding the never-agreed-on AFNOR-proposed work plan. The
> only alternative interpretation I could think of is that the AFNOR
> delegation incorrectly perceived a change in position by the US to the
> New Work Item that defines the goal of WG16. Since the latter
> interpretation is illogical, I adopted the other one.
I think you were right to adopt the other one.
Jeff Dalton, JANET: J.Dalton@uk.ac.ed
AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
∂22-Dec-88 1545 ruben@apple.com Re: Philosophy Colloquium Dec. 9
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Dec 88 15:45:19 PST
Received: from apple.com by csli.Stanford.EDU (4.0/4.7); Thu, 22 Dec 88 15:28:01 PST
Received: by apple.com (5.59/25-eef)
id AA05736; Thu, 22 Dec 88 15:27:46 PST
Received: by goofy.apple.com (4.12/25-eef)
id AA09677; Thu, 22 Dec 88 15:16:59 pst
Date: Thu, 22 Dec 88 15:16:59 pst
From: Ruben Kleiman <ruben@apple.com>
Message-Id: <8812222316.AA09677@internal.apple.com>
To: HOFFMAN@CSLI.Stanford.EDU, hoffman@csli.Stanford.EDU
Subject: Re: Philosophy Colloquium Dec. 9
Cc: forum-faculty@csli.Stanford.EDU, ssp-forum@csli.Stanford.EDU
Hello. March 10 is fine with me. I am not sure that I will want
to exclusively deal with ontological problems, so the title is
tentative now. I will give you a better title after the holiday
vacations.
Thanks and have an interesting holiday.
Ruben Kleiman
∂22-Dec-88 1709 @Score.Stanford.EDU:RWF@SAIL.Stanford.EDU The Way We Were
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Dec 88 17:05:57 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 22 Dec 88 17:04:14-PST
Message-ID: <4Ut#M@SAIL.Stanford.EDU>
Date: 22 Dec 88 1646 PST
From: Robert W Floyd <RWF@SAIL.Stanford.EDU>
Subject: The Way We Were
To: faculty@SCORE.Stanford.EDU
Ed Feigenbaum says we used to be a research-oriented department,
not a "cram-material-for exams" department. Ed is wrong. The
comprehensive system here replaced a much more onerous and
time-consuming system. When I came here in 1968, there were
five qualifying exams in CS. A student got five shots at
passing three of them. When a student had flunked two, he
couldn't afford to fail again, so he put off any other attempts
as long as possible, specifically to his fifth year. So we had
fifth-year students who had not yet been admitted to candidacy.
With the comp system, most students meet their breadth requirement
in their first year, last I knew. Having met it, they have the
security of knowing that they will not be kicked out if they
make reasonable progress. While the comp may well have become
too big and hard, it is still, as a system, much more reasonable
and less demanding than what preceded it.
Feigenbaum has for years told incoming students to ignore courses
and do research. I have remained skeptical. Does anyone out there
have experience with the results of the research-only approach?
It seems to me that such an approach, in effect, says that there
is no value in studying last years research before doing this year's.
If so, why is this year's research going to be worth doing?
∂23-Dec-88 0811 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Complete axiom sets for arithmetic equations
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Dec 88 08:11:51 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA12112; Fri, 23 Dec 88 08:11:28 PDT
Message-Id: <8812231611.AA12112@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Fri, 23 Dec 88 08:11:51 PST
Received: by BYUADMIN (Mailer R2.01A) id 9717; Fri, 23 Dec 88 09:10:24 MST
Date: Fri, 23 Dec 88 10:02:07 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
lescanne%POINCARE.CRIN.FR@Forsythe.Stanford.EDU
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: lescanne%POINCARE.CRIN.FR@Forsythe.Stanford.EDU
Subject: Complete axiom sets for arithmetic equations
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Albert Meyer is right, but Martin's example is (obviously ?) provable
by Peano arithmetic and is not provable by the set of identities.
Therefore it is a counterexample for Rittri's question.
Pierre LESCANNE
Centre de Recherche en Informatique de Nancy (CNRS)
telephone: (work) 83 91 21 19 (country code is 33) (home) 83 22 76 92
e-mail: lescanne@poincare.crin.fr
post: BP 239, F54506 VANDOEUVRE Cedex FRANCE
∂23-Dec-88 0823 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Center for Discrete Mathematics and Theoretical Computer Science
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Dec 88 08:23:17 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA12172; Fri, 23 Dec 88 08:22:59 PDT
Message-Id: <8812231622.AA12172@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Fri, 23 Dec 88 08:23:22 PST
Received: by BYUADMIN (Mailer R2.01A) id 0017; Fri, 23 Dec 88 09:20:56 MST
Date: Fri, 23 Dec 88 10:00:04 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Bernard Chazelle <chazelle%PRINCETON.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Bernard Chazelle <chazelle%PRINCETON.EDU@Forsythe.Stanford.EDU>
Subject: Center for Discrete Mathematics and Theoretical Computer Science
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
****************************************************
CENTER FOR DISCRETE MATHEMATICS
AND THEORETICAL COMPUTER SCIENCE
Special Year 1989-90
Discrete and Computational Geometry
Applications are invited for visiting and
post-doctoral positions in the Center for Discrete Mathematics and
Theoretical Computer Science (DIMACS). This center is supported through
the NSF Science and Technology Centers Research Program.
The participating institutions are Rutgers University,
Princeton University, AT&T Bell Laboratories
and Bell Communications Research. Research facilities are located at the
Rutgers and Princeton campuses.
The purpose of the center is to
address a generally recognized need to understand
fundamental mathematical issues of computation. Applicants
are sought in all areas of discrete mathematics and theoretical
computer science, including (but not limited to) analysis of algorithms,
combinatorics, complexity, computational algebra, discrete and computational
geometry, discrete optimization and graph theory.
The Center will be able to offer
long- and short-term visiting positions. In addition, some regular
positions at the participating institutions may also be available.
A primary activity of the Center is to sponsor year-long research programs
on specific topics of current interest. The topic for 1989-90 is
"Discrete and Computational Geometry". People with expertise in this
area are particularly encouraged to apply. During this year the Center will
sponsor a number of long-term visitors with research interests in discrete and
computational geometry, as well as short-term research workshops in these
areas to which a larger number of participants will be invited. In addition,
the Center is planning a number of other research and educational activities,
which will be announced at a later time.
Postdoctoral and junior applicants
must demonstrate superior research and scholarship potential.
Senior applicants must have an exceptional record of research achievement.
Successful candidates will pursue an active research
program and participate in the activities of the Center.
Direct all inquiries to:
Professor Daniel Gorenstein, Director
DIMACS
Hill Center for the Mathematical Sciences\cr
Rutgers University
New Brunswick, NJ 08903
Arpanet: dimacs@aramis.rutgers.edu
All participating institutions are equal opportunity / affirmative
action employers.
∂23-Dec-88 0825 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Announcement: DIMACS and Special Year.
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Dec 88 08:24:57 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA12187; Fri, 23 Dec 88 08:24:39 PDT
Message-Id: <8812231624.AA12187@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Fri, 23 Dec 88 08:25:02 PST
Received: by BYUADMIN (Mailer R2.01A) id 0079; Fri, 23 Dec 88 09:21:54 MST
Date: Fri, 23 Dec 88 10:03:58 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Mike Grigoriadis <grigoria%ZENO.RUTGERS.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Mike Grigoriadis <grigoria%ZENO.RUTGERS.EDU@Forsythe.Stanford.EDU>
Subject: Announcement: DIMACS and Special Year.
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
The following is a TEX file containing an announcement of the
newly-formed Discrete Mathematics and Theoretical Computer Science
Center and of its first ``special year'' on Discrete and Computational
Geometry.
Please be kind enough to post it and pass it on.
Thank you.
\nopagenumbers
%\hsize3.5in\hfuzz2pt
\magnification=\magstep1
\tolerance=1600
\centerline{\bf CENTER FOR DISCRETE MATHEMATICS}
\centerline{\bf AND THEORETICAL COMPUTER SCIENCE}
\bigskip
\centerline{\bf Special Year 1989-90}
\centerline{\bf Discrete and Computational Geometry}
\bigskip
Applications are invited for visiting and post-doctoral positions in
the Center for Discrete Mathematics and Theoretical Computer Science
(DIMACS). This center is supported through the NSF Science and
Technology Centers Research Program. The participating institutions
are Rutgers University, Princeton University, AT\&T Bell Laboratories
and Bell Communications Research. Research facilities are located at
the Rutgers and Princeton campuses.
The purpose of the center is to address a generally recognized need to
understand fundamental mathematical issues of computation. Applicants
are sought in all areas of discrete mathematics and theoretical
computer science, including (but not limited to) analysis of
algorithms, combinatorics, complexity, computational algebra, discrete
and computational geometry, discrete optimization and graph theory.
The Center will be able to offer long- and short-term visiting
positions. In addition, some regular positions at the participating
institutions may also be available.
A primary activity of the Center is to sponsor year-long research
programs on specific topics of current interest. The topic for
1989-90 is {\bf Discrete and Computational Geometry}. People with
expertise in this area are particularly encouraged to apply. During
this year the Center will sponsor a number of long-term visitors with
research interests in discrete and computational geometry, as well as
short-term research workshops in these areas to which a larger number
of participants will be invited. In addition, the Center is planning
a number of other research and educational activities, which will be
announced at a later time.
Postdoctoral and junior applicants must demonstrate superior research
and scholarship potential. Senior applicants must have an exceptional
record of research achievement. Successful candidates will pursue an
active research program and participate in the activities of the
Center.
Direct all inquiries to:
\medskip
\centerline{\vbox{\halign{&#\hfil\cr
Professor Daniel Gorenstein, Director\cr
DIMACS\cr
Hill Center for the Mathematical Sciences\cr
Rutgers University\cr
New Brunswick, NJ 08903\cr
Arpanet:cdimacs@aramis.rutgers.edu\cr}}}\medskip
All participating institutions are equal opportunity\slash affirmative
action employers.
\end
∂23-Dec-88 1747 @Score.Stanford.EDU:eaf@sumex-aim.stanford.edu Re: The Way We Were
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Dec 88 17:46:58 PST
Received: from sumex-aim.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 23 Dec 88 17:07:22-PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA08014; Fri, 23 Dec 88 17:06:39 PST
Date: Fri, 23 Dec 1988 17:06:38 PST
From: Edward A. Feigenbaum <eaf@sumex-aim.stanford.edu>
To: Robert W Floyd <RWF@sail.stanford.edu>
Cc: faculty@score.stanford.edu, eaf@sumex-aim.stanford.edu
Subject: Re: The Way We Were
In-Reply-To: Your message of 22 Dec 88 1646 PST
Message-Id: <CMM.0.88.598928798.eaf@sumex-aim.stanford.edu>
Bob Floyd's riposte should not go unanswered, although that is my
normal tendancy in long-winded debates like this.
He may be right about what the exam system was in 1968. I don't
remember the details of comps/quals/etc. I just recall that students
in their first and second years were busily engaged in doing
research and exercising their creativity, rather than being
enmeshed deeply in a course structure.
Bob asks the question "How will they learn about last year's
research?" To state the obvious, today's research exists only in the
context of all of the research that has been done in the area up to
"today". Today's research makes salient the need to go back and
read the articles/books/results of many yesteryears. I.e. one's
learning is driven by the problem, not by sitting in a classroom
absorbing lectures
This particular portion of the debate goes back a long time, at least to
the time of John Dewey and perhaps earlier. It is strongly coupled to
another debate about whether the training of a Ph.D. scientist is
primarily an "apprenticeship training" of a very high-level kind, or
or whether it is a more organized (rigidified?) disciplinary
indoctrination.
I havn't followed what CMU or MIT are doing these days with regard to
this question. If one wants to study the research-only experience, I
believe it exists in its pure form in the D.Phil degrees at Oxford
and Cambridge.
Incidentally, to clarify my position (so that Bob does not get to define
it), I do not advocate research-only. I advocate testing breadth with the
comprehensive exam. I advocate that new students plunge into research
work as soon as they arrive, and that they learn what they need to learn
for the comprehensive exams by self-study, eschewing the forced discipline
of courses/assignments/course exams. This enables them to learn the way
they are going to learn for the rest of their research lives. And plunging
directly into research fans the spark of creativity that they bring here,
rather than snuffing it out in course lectures and procedures.
Ed Feigenbaum
∂25-Dec-88 1351 @polya.Stanford.EDU:coraki!pratt@Sun.COM Minimal models
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Dec 88 13:51:01 PST
Received: from SUN.COM by polya.Stanford.EDU (5.59/25-eef) id AA05394; Sun, 25 Dec 88 13:47:15 PDT
Received: from sun.Sun.COM (sun-bb.sun.com) by Sun.COM (4.1/SMI-4.0)
id AA03296; Sun, 25 Dec 88 13:49:33 PST
Received: from coraki.UUCP by sun.Sun.COM (4.0/SMI-4.0)
id AA14881; Sun, 25 Dec 88 13:46:49 PST
Received: by (4.0/SMI-4.0Beta)
id AA06034; Sun, 25 Dec 88 13:45:57 PST
Date: Sun, 25 Dec 88 13:45:57 PST
From: Vaughan Pratt <coraki!pratt@Sun.COM>
Message-Id: <8812252145.AA06034@>
To: lop@cs.stanford.edu
Subject: Minimal models
Cc: coraki!pratt@Sun.COM
+ Conditional logics. Nonmonotonic, nontransitive consequence relations.
(M |= A->B iff N|=B for the "minimal revision" N of M such that N|=A.)
The following does not address Tom's main question about connections
between minimal models, but rather explores aspects of the above
notion.
If we write p->q for material implication (1->0 = 0, 0->1 = 0->0 = 1->1
= 1) and p=>q for strict (necessary material) implication, we may
relate the two via
p=>q = [](p->q)
That is, strict implication is necessary material implication.
*
This idea has a long history dating back to Aristotle and Diodorus,
further pursued by various medieval writers, and formalized as above by
C.I. Lewis and K. Goedel, modulo the choice of glyphs for <> and [] (L
and M were popular then). Also Lewis wrote !<>(p&!q), which Goedel
tidied up as [](p->q), see the Lemmon Notes, Monograph #11 of the
American Philosophical Quarterly, ed. K. Segerberg, 1977.
In dynamic logic material implication p->q can be written [p?]q. If we
write [] as [N] where N is the action of going to a neighboring
possible world, then p=>q becomes [N][p?]q, or [N;p?]q, where N;p? is
the composite action of first going to a neighboring world and then
testing whether p holds, diverging if not.
From this point of view we may relate minimal-revision implication to
strict implication by replacing N by a smaller action p# that goes no
further than is needed to bring about p.
Here are some random thoughts about how "no further than needed" might
be formalized, and some of its consequences. I don't know how this
relates to extant notions of minimal revision.
If we impose a (not necessarily symmetric) distance metric d(u,v) on
possible worlds, we can define p# to be the set of pairs (u,v) of
possible worlds (states) such that for all w|=p, d(u,v) <= d(u,w).
(This definition does not force p# to be either deterministic or
total.) This makes p#, at each u, the greatest ball centered on u not
having p in its interior. Abbreviate p#;p? to p!. p! is the action
that ensures p at minimal cost. At each u, p! is that portion of the
surface of p# satisfying p. It is possible that there is no least-cost
way of ensuring p, in which case p! will be empty.
As an example d(u,v) may be the number of variables that differ between
u and v. If P(x) (i.e. P with one free variable x) holds for exactly
one value z of x, write P(x) as x=z. assignment statement x:=z. Then
(x=3)# acts as x:=? (random assignment) except when x is already 3, in
which case it acts as the identity (no change), while (x=3)! is the
assignment statement x:=3.
For an arithmetic universe, d(u,v) might be made the distance from u to
v under some Lp metric, e.g. Euclidean (p=2). Then (x=3)# becomes at
each u the sphere centered at u and having the plane x=3 as a tangent
plane, while (x=3)! is still x:=3 (why?). Whereas (x=y)# is still a
sphere at each u, (x=y)! is a deterministic action making the minimal
change to x and y (under the Euclidean metric) needed to bring them
together.
One disconcerting feature of minimal-revision implication is that
worlds lying just outside p# have no influence. Whatever shape the
necessity action N has, one does not ordinarily expect it to cut off
sharply at some point.
-v
====================
* Diodorus died of shame c. 307 B.C. when he was unable to solve a logic
problem posed by Stilpon. Should the MTC qual raise its standards?
∂26-Dec-88 1541 @Score.Stanford.EDU:daniel@mojave.Stanford.EDU Ph.D. research: the difference between exam requirements and course requirements.
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Dec 88 15:41:02 PST
Received: from mojave.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 26 Dec 88 15:38:42-PST
Received: by mojave.Stanford.EDU (5.59/inc-1.0)
id AA03289; Mon, 26 Dec 88 15:39:23 PDT
Date: Mon, 26 Dec 88 15:39:23 PDT
From: daniel@mojave.Stanford.EDU (Daniel Weise)
Message-Id: <8812262339.AA03289@mojave.Stanford.EDU>
To: RWF@SAIL.Stanford.EDU
Cc: linton@LURCH.STANFORD.EDU, faculty@SCORE.Stanford.EDU
In-Reply-To: Robert W Floyd's message of 21 Dec 88 1348 PST <14Tx8$@SAIL.Stanford.EDU>
Subject: Ph.D. research: the difference between exam requirements and course requirements.
I think a PhD should be able to teach any intro level core CS course.
You know, I absolutely agree with this statement. But it has nothing
to do with what the comps are about. I can teach any intro level core
CS course (having taught architecture, compilers, programming
langauges, and AI, I'm only missing an automata/computability course
to cover all bases), but I can't pass the comps. There's just TOO
MUCH THERE.
The emperor has no clothes: Stanford students no longer make an impact
in the world. Halpern already mentioned theory. We have yet to get
any dissertation to even place in the ACM dissertation award contest.
MIT always at least places. Our students don't get faculty positions
at MIT (Agrawal was an EE student!), CMU (Gross is research faculty),
or Berkeley. MIT and CMU students regularly get jobs at the top four.
We admit the same caliber student as Berkeley, MIT, and CMU, but we
aren't training them properly as researchers. As David Dill points
out, the problem is one of atmosphere and messages. The message must
be "research is the reason you are here." This must be the primary
message. Narrowing the scope of the comps is only one part of getting
this message across, but it is a necessary part.
Daniel
∂27-Dec-88 1134 @Score.Stanford.EDU:jlh@vsop.Stanford.EDU Re: Ph.D. research: the difference between exam requirements and course requirements.
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Dec 88 11:34:53 PST
Received: from vsop.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 27 Dec 88 11:32:23-PST
Received: from LOCALHOST by vsop.Stanford.EDU (5.59/inc-1.0)
id AA06462; Tue, 27 Dec 88 11:17:45 PDT
Message-Id: <8812271917.AA06462@vsop.Stanford.EDU>
To: faculty@SCORE.Stanford.EDU
Subject: Re: Ph.D. research: the difference between exam requirements and course requirements.
In-Reply-To: Your message of Mon, 26 Dec 88 15:39:23 -0700.
<8812262339.AA03289@mojave.Stanford.EDU>
Date: Tue, 27 Dec 88 11:17:40 PST
From: jlh@vsop.Stanford.EDU
Some observations:
1. The comps have become too difficult. I believe that almost any CS
undergrad that we admit should pass the comps in the first year. I
am not sure that our own undergrads could do this.
2. We award students PhD candidacy after they pass the comps (the
university requires this within two years). Courses and degress says
"Admission to candidacy is an acknowledgement of the student's
potential to complete successfully the rquirements for the Ph.D." The
intention is clearly that students have passed the necessary exams - in
fact courses and degrees calls the exams leading to candidacy "the
departmental qualifying procedures". Are we the only department that
administers another exam after candidacy but before the oral exam?
(Some departments use the university oral the way we use the qualifying
exams.)
3. We don't normally sort systems students by department, but Daniel's
message encouraged me to do it. Here are some (not necessarily all) of
Stanford's best recent systems students that went to top academic
places: Gross(CMU), Agarwal(MIT), Marzullo(Cornell), Gifford(MIT),
Spector(CMU). Only Spector was CS. This is NOT because the EE students
are better. But, the top EE people easily pass the EE quals the first
year and then they forget about exams and concentrate on research. They
have all published papers BEFORE they settled down on a thesis topic. I
don't think the above students graduated in much less than the average
term (5 years), but each of them had several publications when they
graduated.
John
∂27-Dec-88 1445 LOGMTC-mailer Model theoretic properties of universal horn sentences
Received: from russell (Russell.Stanford.EDU) by SAIL.Stanford.EDU with TCP; 27 Dec 88 14:45:38 PST
Received: from [127.0.0.1] by russell (4.0/4.7); Tue, 27 Dec 88 11:13:15 PST
To: logic@russell
Cc: ynm@math.ucla.edu
Subject: Model theoretic properties of universal horn sentences
Date: Tue, 27 Dec 88 11:11:42 PST
From: Jon Barwise <barwise@russell>
I once heard a talk at Oberwolfach by a German logician on the
above topic. He was interested in those properties that made
horn clauses particularly suitable for computational purposes.
But I can remember nothing more about the talk, like who gave it.
Does anyone know anything about this work, or about other discussions
of the same topic?
Any help will be appreciated.
Jon
∂27-Dec-88 1659 @Score.Stanford.EDU:binford@Boa-Constrictor.Stanford.EDU comps
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Dec 88 16:58:08 PST
Received: from Boa-Constrictor.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 27 Dec 88 16:55:43-PST
Received: by Boa-Constrictor.Stanford.EDU.stanford.edu (4.0/SMI-DDN)
id AA03889; Tue, 27 Dec 88 16:48:14 PST
Date: Tue, 27 Dec 88 16:48:14 PST
From: binford@Boa-Constrictor.stanford.edu (Tom Binford)
Message-Id: <8812280048.AA03889@Boa-Constrictor.Stanford.EDU.stanford.edu>
To: faculty@score
Subject: comps
To continue the debate on comps, courses, and research.
I personally think that research is top priority and
the starting place. Perhaps breadth vs depth is not an
"either/or". I also think that courses are valuable.
I propose that we change the order. We now require
demonstration of breadth before research. I propose that we
begin students with research from the beginning and that we
require the demonstration of breadth late in the PhD
program. It is natural for people to take courses while
doing research. The majority of my students take courses
which are not directly associated with requirements,
especially a succession of math courses.
It does not matter when breadth is satisfied, or how
it is satisfied. I like the comp myself. The comp itself
can be a good experience, a time when students peak in
breadth. It is a chance for integration that is valuable.
Courses can also demonstrate breadth. However, as Floyd has
pointed out, this can be suspect.
Perhaps the most students who have problems
encounter problems with research. It is best to find
problems as early as possible for those who have problems.
Some may not have background and may require time to
develop. Some may not have the motivation or orientation
for research.
There are several questions that occur. One is that
comps are a filter before research in the PhD process. I do
not think that the comps are a useful filter, that they are
correlated with research potential. Another question is
that it takes time to take courses, etc. True. I think
that a student's purpose is to do science, not to find a
minimum path through requirements for a union card. Another
is that students require background for research. True,
their advisors should guide them to get this background.
Recently, we have promoted taking courses
exclusively before research. This discussion series is a
re-thinking of priorities. I think that we are becoming
increasingly rigid about observable milestones. When we
began, this was intended to motivate students to make
progress in order to cut their time through the program.
Now it is much more bureaucratic. I suggest that we return
to our original motivation.
Tom Binford
-------
∂28-Dec-88 1229 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu The *Other* Unification Algorithm, I
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Dec 88 12:29:25 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA13044; Wed, 28 Dec 88 12:28:49 PDT
Message-Id: <8812282028.AA13044@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Wed, 28 Dec 88 12:29:14 PST
Received: by BYUADMIN (Mailer R2.01A) id 2772; Wed, 28 Dec 88 13:24:47 MST
Date: Wed, 28 Dec 88 13:39:33 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Mark William Hopkins <markh%CSD4.MILW.WISC.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Mark William Hopkins <markh%CSD4.MILW.WISC.EDU@Forsythe.Stanford.EDU>
Subject: The *Other* Unification Algorithm, I
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
If you are given two patterns:
f ?x (g ?x a) (h ?y) and f (h ?z) ?y (h ?z)
then you may have been taught that the Unification of these two patterns is
derived by making appropriate substitutions for the pattern variables ?x and ?y
in the first pattern, ?y and ?z in the second in such a way that the two
results match. There is an algorithm to do this procedure which is called
Pattern Unification. Yet there is a completely different type of "unification"
which is never mentioned in that context. I am going to compare the two
algorithms here.
This is a simple illustration of how Pattern Unification works. Take the
two patterns
f ?x (g ?x a) (h ?y) f (h ?z) ?y (h ?z)
and parse them:
f ?x (g ?x a) (h ?y) f (h ?z) ?y (h ?z)
becomes (0), where: becomes (5), where:
(0) = f (3) (1) (2) (5) = f (6) (7) (6)
(1) = g (3) a (6) = h (8)
(2) = h (4) (7) = ?y
(3) = ?x (8) = ?z
(4) = ?y
The labels (1), (2), etc. inside each string represents pointers to the string
with the given label. Pattern variables are represented as empty parses in
such a way that distinct variables have distinct labels. Each of these two
parses is a graph, and the unification algorithm is a particular kind of graph
traversal algorithm. I choose to represent it here is a Breadth First Search
traversal.
The algorithm goes as follows: to unify (0) and (5), unify each of the
components of the corresponding strings. When two patterns fail to unify,
we represent the result by the "null-pattern" (), (my terminology) which
satisfies the axiom:
if S = a1 ... an and ai = () for and i, then S = ().
that is, any string containing the null pattern reduces to the null pattern.
So we match (0) and (5). As a result we are required to match (3)/(6),
(1)/(7) and (2)/(6). When we get to (3), we see that (3) is a "more general"
pattern than (6) ... it can be reduced to (6) by an appropriate substitution
for the variable ?x. So we set (3) to (6). The new table entry becomes:
(3) = (6).
Matching (1) to (7) creates a new table entry:
(7) = (1).
When we match (2) to (6), we find that we have to match (4) to (8). Both
entries are equally general and so either can be bound to the other. We'll
bind (8) to (4) to create the new entry:
(8) = (4).
The final result is the table:
(0) = f (3) (1) (2) (5) = f (6) (7) (6)
(1) = g (3) a (6) = h (8)
(2) = h (4) (7) = (1)
(3) = (6) (8) = (4)
(4) = ?y
Pattern unification does not allow for recursively defined patterns, so we need
to check to ensure that the graph does not have any cycles in it. In the
process we may eliminate those vertices that cannot be reached from (0) to get
and "dereference" the bound variables (3), (7) and (8) to get:
(0) = f (6) (1) (2)
(1) = g (6) a
(2) = h (4)
(6) = h (4)
(4) = ?y
The final result of the unification of the two patterns:
f ?x (g ?x a) (h ?y) f (h ?z) ?y (h ?z)
is:
f (h ?y) (g (h ?y) a) (h ?y)
Yet there is another kind of unification algorithm. This other algorithm
attempts to derive the most specific pattern C that is more general than two
given patterns A or B. A and B can both be derived from C by substituting
appropriate variables in C, for example:
if A = f ?x a and B = f b ?y
then
C = f ?x ?y
Unification does the opposite. The algorithm uses the same parse table as
above but performs the bindings in a slightly different way. To apply the
other algorithm on the two patterns:
f ?x (g ?x a) (h ?y) f (h ?z) ?y (h ?z)
we proceed in the following way. We form the parse tables:
f ?x (g ?x a) (h ?y) f (h ?z) ?y (h ?z)
becomes (0), where: becomes (5), where:
(0) = f (3) (1) (2) (5) = f (6) (7) (6)
(1) = g (3) a (6) = h (8)
(2) = h (4) (7) = ?y
(3) = ?x (8) = ?z
(4) = ?y
and then match (0) to (5). This entails matching (3)/(6), (1)/(7) and (2)/(6)
as before. In the first match, (6) is less general than (3). The binding will
occur in the opposite direction. However, the entry (6) is left untouched.
What will be changed is only the label (6) which occurs in the string (5), not
the string (6), itself. The new table entry is thus:
(5) = f (3) (7) (6)
Matching (1)/(7) entails a similar change for the entry (0):
(0) = f (3) (7) (2)
Finally, matching (2)/(6) entails matching (4)/(8). As before, since both
patterns are equally general, we can bind either to the other. We choose to
bind (8) to (4). Thus, the new table entry for (6) is:
(6) = h (4).
This leaves us with the table:
(0) = f (3) (7) (2) (5) = f (3) (7) (6)
(1) = g (3) a (6) = h (4)
(2) = h (4) (7) = ?y
(3) = ?x (8) = ?z
(4) = ?y
which, when reduced, gives us:
(0) = f (3) (7) (2)
(3) = ?x
(7) = ?y
(2) = h (4)
(4) = ?z
(since (4) and (7) are distinct labels that thereofre represent distinct
variables, one of them has been rewritten)
The final result of this other unification algorithm on
f ?x (g ?x a) (h ?y) f (h ?z) ?y (h ?z)
is
f ?x ?y (h ?z)
------------------------------------------------------------------------
Date: 27 Dec 88 22:30:17 GMT
From: markh@csd4.milw.wisc.edu (Mark William Hopkins)
Organization: University of Wisconsin-Milwaukee
Subject: Re: The *Other* Unification Algorithm, II
Message-Id: <117@csd4.milw.wisc.edu>
This is a followup on the previous article posted on this topic.
Underlying unification algorithms presented in that article is a theory
of syntatic patterns, which I will try to outline here.
Consider a specific grammar G:
S --> NP VP
NP --> D N
VP --> V NP
D --> 'the' | 'a'
N --> 'boy' | 'girl' | 'child'
V --> 'saw' | 'kissed' | 'loves' | 'hit'
A syntatic pattern is an expression formed with this grammar by adding pattern
variables. Pattern variables are denoted here by identifiers preceded by
question marks, e.g. ?x. A pattern variable denotes an arbitrary entity of one
of the classes, S, NP, ..., V -- this class is referred to as the variable's
type. A variable's type is assumed to be given a priori.
In addition, lambda abstractions are allowed. For example:
F = lambda ?x: NP ( ?x kissed the girl)
denotes the function which takes a NP argument and produces the result as
indicated in the brackets. For example:
F[the boy] = [the boy kissed the girl]
The type of this function is denoted as (NP --> S).
Underlying these considerations is a type system for syntatic patterns.
This system is defined a set of type matching rules for each non-terminal in
the grammar; the rules are generated from the grammar itself. For example,
the type matching rules for the class S are:
(I) ?x: S if and only if ?x denotes an arbitrary member of S.
(II) if np: NP and vp: VP then np vp: S
In addition for these type matching rules, there are type matching rules for
lambda abstractions:
(I) if ?x: N1 and f(?x): N2 then (lambda ?x. f(?x)): N1 --> N2
(II) if f: N1 --> N2 and n: N1 then (f n): N2
For each type, the pattern space has a partial ordering defined on it.
For example, if A and B are patterns of type S, then
A Less1 B if and only if A = (lambda ?x.B) n
for some pattern variable ?x and compatible pattern n. This states that
A is a less general pattern than B and can be derived from B by substituting
for one pattern variable. The partial ordering, Less, is defined as the
reflexive/transitive closure of this relation.
Since we have a partial ordering, we can define least upper bounds and
greatest lower bounds. This is where the previous article figures in. The
greatest lower bound of two patterns is the result obtained by the Unification
Algorithm. The least upper bound is obtained by the Other Unification
Algorithm discussed in that article.
For reference, I will denote this least upper bound as the Abstraction of
the two patterns and will call the algorithm Abstraction Unification. Given
two pattern A, B if their abstraction is a pattern C then the following is
true:
A = lambda ?x1. ... (lambda ?xm. C) n1 ... nm
B = lambda ?y1. ... (lambda ?yn. C) p1 ... pm
For example, for the two patterns:
?np kissed the girl, the boy ?vp
the abstraction is:
?np ?vp
and
?np kissed the girl = ( lambda ?vp. (?np ?vp) ) [kissed the girl]
the boy ?vp = ( lambda ?np. (?np ?vp) ) [the boy]
Another example:
?np kissed the girl, ?np hit the boy
gives:
?np ?v the ?n
where:
?np kissed the girl = lambda ?v. lambda ?n.(?np ?v the ?n) [kissed] [girl]
?np hit the boy = lambda ?v. lambda ?n.(?np ?v the ?n) [hit] [boy]
It is here that we see the significance of Abstraction Unification: It is a
*syntatic pattern recognition* algorithm, capable of inducting parametrized
patterns from a set of instances.
∂28-Dec-88 1337 aaai@sumex-aim.stanford.edu NTU
Received: from sumex-aim.stanford.edu by SAIL.Stanford.EDU with TCP; 28 Dec 88 13:37:16 PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA13913; Wed, 28 Dec 88 13:27:26 PST
Date: Wed, 28 Dec 1988 13:27:24 PST
From: AAAI <aaai@sumex-aim.stanford.edu>
To: officers:;@sumex-aim.stanford.edu
Cc: aaai@sumex-aim.stanford.edu
Subject: NTU
Message-Id: <CMM.0.88.599347644.aaai@sumex-aim.stanford.edu>
Dear Councilor:
About a month ago, I sent out an extensive site visit report to the
National Technological University regarding the possibility of the
AAAI sponsoring its tutorials over their satellite network. So
far I have only received two responses to the questions in the report.
Could you please review the attached report and send me your comments
soon? They are expecting some response from us by early January
regarding our intention to pursue this venture or not.
Thanks,
Claudia
Monday, November 21, 1988
Visit to National Technological University, Ft. Collins, Co.
On the above date, I visited with Dr. Lionel Baldwin, President of NTU, and
Richard Soderberg, Director of NTU Professional Development Programs. The
purpose of my visit was to review their facilities, discuss their organization-
al, marketing and sales structures, and review possible financial arrangements
for the satellite transmitted tutorials as professional development courses.
NTU is a program with the Association for Media-based Continuing Education for
Engineers (AMCEE). Incorporated in 1985, the association divided its credit
versus non-credit courses between NTU and a group in Georgia. In 1987,
NTU assumed the responsibilities of both credit and non-credit programs.
NTU is a non-profit organization identified under the IRS code 501 (c) (3)
and 509 (a) (1). NTU has a staff of 20 people. They have studio sites
in about 7 locals across the country.
FINANCIAL STRUCTURE
NTU provides courses to over 230 different sponsoring corporate sites and
25 member universities. Each sponsoring site pays an annual fee to NTU to
use their satellite network. In addition to the annual fee, each sponsoring
site will pay a regisitration fee for each course. Usually the registration
fee is based on a graduated scale beginning with approximately $200 a person
for a full day course (4 1/2 hours of lecture) up to 6 attendees.
After 6 registrants, it is $1250 per course per site. Each course collects
$36-42,000 gross revenue per tutorial.
The typical financial arrangement with NTU and outside organization follows:
* NTU receives 40% gross revenues; they are responsible for all
marketing and sales; invoicing of the sites, transponder time
for the broadcast, accounts receivable collection and distribution
of funds.
* Organization receives 60% gross revenues; they are responsible
for the selection of the tutorial, payment to the speakers,
studio and uplink facility and costs to the mailing of the
tutorial syllabi to the sites.
We could expect between $10-16,000 net revenues per tutorial. Presently
we net about $27,000 per tutorial.
In addition after a review of their 1987-1988 Annual Report, NTU is barely
breaking even with their expenses outweighting their revenues in 1987-88.
They have a sizeable accounts receivables with their investment in the
physical facilities as their primary assets. I have a copy of the
report in my office if you would like to review it.
Marketing/Sales Efforts
NTU uses each site's coordinator as the primary mechanisms to distribute
their promotional literature about each quarter's course offerings. Each
month NTU mails to 12,000 names their course offering catalogue and updates.
They do no display advertising, but sponsor a free week long management
seminar to find new students and site sponsors. They feel that live
presentations is the best demonstration of the network's capabilities
and the best form of advertising.
For their professional development courses, they do no marketing
research to determine what courses their sites sponsors want to attend.
Their approach is to simply send a list of prospective course outlines
to their site sponsor's coordinators and ask them to see if anyone in
their organization is interested in these courses. This is clearly the
weak link in their advertising efforts.
They do very little evaluation of their courses to determine the
adequacy of their speakers and course content.
They limit their sales efforts to the domestic marketplace and have not
begun to explore any foreign network distribution of their professional
development courses.
OPERATIONS
The AAAI would be responsible in preparing a first draft of course
selections. NTU would then distribute that list to their site sponsor's
coordinator and get their feedback. After a determination of final
course offerings was made, then we would create our own speaker
fee contract and set up a schedule with NTU and the speaker.(They have already
suggested four tutorials for 1989). The speaker would then go to one of the
studio sites and simply give his lecture as if he or she was in a
classroom.
IEEE AND ACS
At this time only IEEE produces courses on this network. However they
do their own advertising, studio broadcasting, etc (the works!), and
they apparently lose money. IEEE only uses the satellite network and
some advertising organs of NTU. ACS is still formulating its program
and hopefully it will be implemented in 1989.
TRENDS
There is a growing trend for large corporations to establish their own
satellite networks (ie IBM, HP) and offer their own classes.
NTU is linking into these networks at this time.
The motivation for the establishment of these private networks
is to cut the costs of corporate educational efforts by offering
courses. Presently, it costs a corporation $350 per day to send
someone to an off-site class while an internal class is $150 per day.
At some point the growth of alternative delivery methods
of educational offerings will eat into our tutorial revenues. At
this time, there is no evidence that our tutorial revenues are
dropping.
COMMENTS
Clearly, NTU is a young organization, struggling financially at this time,
with a weak marketing and sales structure.
However, if the trend for more internal-derived technical and professional
courses continues, then NTU may be in a very advantageous position in the
future. If AAAI was to establish its own satellite tutorials, then we would
already be in the position to take advantage of any changes in trends.
If the Council were to decide on working with NTU, then we should proceed
slowly and carefully by ensuring that our tutorial revenues are not
cut by our own satellite sponsored tutorials. We may be able to achieve
this by scheduling courses on the satellite network that do not conflict
with our ongoing conference tutorial program.
I would like your comments on the proposal to establish satellite
tutorials. If you need any additional information about NTU, please
send me a message.
Claudia Mazzetti
∂28-Dec-88 1531 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu amended "call for papers" for AMAST Conference
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Dec 88 15:31:20 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA16783; Wed, 28 Dec 88 15:30:41 PDT
Message-Id: <8812282330.AA16783@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Wed, 28 Dec 88 15:31:11 PST
Received: by BYUADMIN (Mailer R2.01A) id 9457; Wed, 28 Dec 88 15:45:49 MST
Date: Tue, 27 Dec 88 09:56:09 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Chic Rattray <cr%CS.STIR.AC.UK@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Chic Rattray <cr%CS.STIR.AC.UK@Forsythe.Stanford.EDU>
Subject: amended "call for papers" for AMAST Conference
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
The following is a slightly amended "call for papers" for the
AMAST Conference to be held at the University of Iowa in May 1989.
-------------------------------------------------------------------------
Second CALL FOR ABSTRACTS
International Conference on
Algebraic Methodology And Software Technology, AMAST
Iowa City, Iowa, May 22-24, 1989
The goal of the conference is to consolidate the trend of using algebraic
methodology as a foundation for software technology showing that universal
algebra provides a practical mathematical alternative to ad hoc approaches
used in software development. Both academia and industry are the benefici-
ary of such a formal foundation.
In order to achieve this goal, we plan to bring together leading research-
ers in mathematics and computer science on a common platform so that alge-
braic methodologies that can be used as a viable alternative to ad hoc
approaches for software development can be identified and the appropriate-
ness of such alternatives in view of actual implementations can be dis-
cussed. The invited speakers include:
Constable, R., Cornell University, Ithaca, New York, USA
Lawvere, W. F., State University of New York at Buffalo, USA
Meseguer, J., SRI International, USA
Nivat, M., The University of Paris, France
Wagner, E., IBM Thomas J. Watson Research Center, USA
The invited talks will cover both valid experiments regarding the use of
algebraic methodology for the development of software technology and frame-
works for guiding further development work in this area.
Talks reporting research in algebra suitable as a foundation for software
technology as well as software technologies developed by means of algebraic
methodologies are welcome. We invite you to submit a two page abstract
(including a few citations of relevant work) of your talk to the address
AMAST CONFERENCE
Computer Science and Mathematics Departments
The University of Iowa
Iowa City, IA 52242, U.S.A.
Important due dates:
(1) Two page abstract submission by February 1, 1989.
(2) Notification of acceptance by March 15, 1989.
(3) Abbreviated four page camera ready papers to be published in
proceeding by April 10, 1989.
A special issue of the journal ``Theoretical Computer Science'' will
be dedicated to this conference and each participant will be invited to
submit a full paper for publication. In addition, four page abbreviated
papers of the talks presented at the conference together with the invited
talks will be published in the proceedings that will be available to the
attendees upon their arrival in Iowa City. Further information can be
obtained from:
In Europe: In U.S.A: In Canada:
-------------------------------------------------------------------------
Prof. Maurice Nivat Prof. Eugene Madison, Math. Prof. Dan Ionescu
Universite Paris Prof. Teodor Rus, Comp.Sci. University of Ottawa
Place Jussieu University of Iowa Department of Elect. Eng.
75005 Paris, France Iowa City, IA 52242 770 King Edward, Ottawa
Phone: (1) 43259874 Phone: (319)-335-0694 Ont. Canada K1N 6N5
e-mail:rus@herky.cs.uiowa.edu Phone: (613)-564-2211
Prof. Charles Rattray e-mail:
Computing Science Dpt. diopb@uottawa.BITNET
University of Stirling
Stirling , FK9 4LA, Scotland
e-mail: cr%compsci.stirling.ac.uk@nss.cs.ucl.ac.uk
The conference will be held at the Conference Center of the University of
Iowa. The Center for Conferences and Institutes will handle hotel reserva-
tion and registration. A block of rooms in the student dormitory will be
available at about $15 a night. A limited number of rooms at the Iowa
Memorial Union guest house at $40 a night are also reserved. For more
information contact:
Bobby C Davis
Center for Conferences and Institutes
The University of Iowa, Iowa Memorial Union
Iowa City, Iowa 52242
Phone (319)335-3231
Limousine services between Cedar Rapids airport and Iowa City are avail-
able.
∂28-Dec-88 2238 @Score.Stanford.EDU:eaf@sumex-aim.stanford.edu Re: comps
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Dec 88 22:37:57 PST
Received: from sumex-aim.stanford.edu by SCORE.STANFORD.EDU with TCP; Wed 28 Dec 88 22:35:58-PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA18175; Wed, 28 Dec 88 22:36:56 PST
Date: Wed, 28 Dec 1988 22:36:56 PST
From: Edward A. Feigenbaum <eaf@sumex-aim.stanford.edu>
To: binford@boa-constrictor.stanford.edu (Tom Binford)
Cc: faculty@score.stanford.edu
Subject: Re: comps
In-Reply-To: Your message of Tue, 27 Dec 88 16:48:14 PST
Message-Id: <CMM.0.88.599380616.eaf@sumex-aim.stanford.edu>
This is just a short one, with a few comments, but I will probably write a
longer one later in the vacation.
It is genuinely exciting for me to watch the department faculty reexamine
some the basics under which it/they operate. Nothing of this importance
(in my opinion) has surfaced during the past several years, perhaps during
all of the 1980s. This discussion is deeply about we stand for.
Comment two. Binford has a genuinely interesting idea in his suggestion to
have the student pass the qual before the comp. That deserves serious
discussion.
Comment three. Regarding the comments that "the comp is getting harder
and harder", I want to comment only on the portion I have participated in
framing (namely the AI material that is included in applications; not the
AI material in "theory"). Honestly, I could not have asked easier questions,
In fact, several of the questions were simply mapped over from mid-terms
or finals of CS123. These were really "kid's questions". And purposely
intended to be so, because we did not want to burden students from the other
areas with having to have any knowledge in depth of the AI literature. For
after all the comp is a test of breadth.
Perhaps this is not being done by other areas. But I plead "not guilty"
to the charge of making comps harder and harder.
I sure wish we could get more of the faculty to participate in this
electronic discussion!
Best holiday wishes to all,
Ed Feigenbaum
∂29-Dec-88 0523 LOGMTC-mailer Re: Model theoretic properties of universal horn sentences
Received: from russell (Russell.Stanford.EDU) by SAIL.Stanford.EDU with TCP; 29 Dec 88 05:23:26 PST
Received: from CSL.SRI.COM by russell (4.0/4.7); Thu, 29 Dec 88 05:25:35 PST
Received: from NSS.CS.UCL.AC.UK by CSL.SRI.COM with SMTP
(5.59e++/IDA-1.2.3-10) id AA02002; Thu, 29 Dec 88 05:21:58 PST
Received: from prg.oxford.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa02580; 29 Dec 88 13:11 GMT
Received: from uk.ac.oxford.prg.client80 (client80) by uk.ac.ox.prg (4.12/prgv.29)
id AA23076; Thu, 29 Dec 88 13:15:41 gmt
Received: by uk.ac.oxford.prg.client80 (3.2/prg.1)
id AA25307; Thu, 29 Dec 88 13:18:20 GMT
Date: Thu, 29 Dec 88 13:18:20 GMT
From: goguen@prg.oxford.ac.uk
Message-Id: <8812291318.AA25307@uk.ac.oxford.prg.client80>
To: logic <logic@russell.stanford.edu>
Subject: Re: Model theoretic properties of universal horn sentences
jon,
perhaps it was bernd mahr, of the technical university of berlin, who gave
the talk you heard. at least, he has published several papers on the subject.
the gist is that horn clause logic is the largest subinstitution of first
order logic that always has initial models (but the exact statement is more
complex).
joseph
∂31-Dec-88 1755 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Happy New Year!
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 31 Dec 88 17:55:38 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Sat 31 Dec 88 17:49:25-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA04228; Sat, 31 Dec 88 17:48:43 PDT
Date: Sat, 31 Dec 88 17:48:43 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8901010148.AA04228@Tenaya.stanford.edu>
To: csd-list@score
Cc: gibbons@sierra, kruger@sierra
Subject: Happy New Year!
Dear faculty, staff, students and friends of computer science at Stanford:
I'll start my traditional end-of-year-summary by reviewing some of the
good news and accomplishments of 1988 (in no particular order):
1) We are extremely fortunate to have persuaded Jeff Eppinger and
Monica Lam to join the CS Department and Theresa Meng to join CSL (as
an EE faculty member). They are the latest additions to a most
outstanding group of young faculty. This group is Stanford's primary
assurance of continued excellence in computer science well into the
future.
2) Our lecturers, Roy Jones, Steve Fisher, and Mike Cleron, are really
doing an outstanding job with the CS introductory courses. Roy has
worked very hard to keep our educational program running smoothly
through the transition caused by Stuart Reges's departure. I am very
happy with the way the undergraduate cs-related majors are evolving.
I don't have the latest figures in front of me, but I believe there are
around 70 or so students each who have declared majors in Computer
Science, in Symbolic Systems, and in Math/Comp.Sci. I believe there
are a dozen or so who have declared in Computer Systems Engineering.
That makes well over 200 total computer-science related majors. We
were also quite lucky to have talked Brian Reid into teaching the
CS109 sequence this year.
3) Research funding is holding up better than some of us thought it
might at this time last year. AI didn't suffer all of the budget cuts
that we thought Jack Schwartz at DARPA might impose, funding for
robotics research looks reasonably bright, industry is stepping up its
funding of basic research, and many elements of our research in
systems are healthy. Our research program is also being enriched by a
number of exciting collaborations with other departments notably
Aero/Astro, Civil Engineering, Electrical Engineering, and Medicine.
There are even signs of improving collaborations with Math.
4) The "mini-lab" concept (for collaborating with industry through
industrial visitors at Stanford) looks like it will be realized in
January 1989 with an experimental "science center" to be established
by Hewlett-Packard. Many of our faculty have worked very hard to help
make this happen, notably Mike Genesereth and Gio Wiederhold. We owe
special thanks to Elliott Levinthal and Jim Gibbons for their hard
work in shaping this idea so that it could receive approval from both
Hewlett-Packard and the Provost's office.
5) The CS Department finished academic year 1987/88 with a dollar
surplus. (The year before we had a deficit.) To have a surplus we
must keep expenses under control (we can thank George Wheaton and
Betty Scott for that), but we must also have larger-than-expected
income (we can thank Carolyn Tajnai and the Computer Forum, WICS, and
the Honors Co-op/SITN program for that).
6) We selected a great architect, Ted Brown, to design the future home
of the CSD (and ISL and much of CSL). Ted has come up with some
outstanding design ideas that are now being refined for Board of
Trustees approval. Although the approval process at Stanford is slower
than we might like it to be, and we are probably a bit behind the
schedule we set a year or so ago, I am optimistic that we'll get final
Board approval this Winter quarter. The process has also involved
intense negotiation with the Provost's office about building size and
space assignments. So far, I'm happy with the results of all of this,
although there still are pressures for putting substantial
university-wide facilities in the building. Jim Gibbons has provided
superb backing for us in everything having to do with the building
project.
7) We have started a new interdisciplinary graduate program,
Scientific Computing and Computational Mathematics, under the
direction of Gene Golub. This program, with participation from
several other Stanford departments, will help us recruit new graduate
students in this important area and regain momentum in that part of
computer science that gave birth to our Department.
Here are some problems and challenges that face us in 1989:
1) Stanford's pre-eminence in the theory and foundations of computer
science must be re-built. During this past year, Christos
Papadimitriou wrote us an official resignation letter; Ernst Mayr left
to take a position in Germany; and Janos Komlos declined our offer of
a faculty appointment. Donald Knuth is leading a committee that is
searching for new faculty in this area. The Department has already
approved a senior faculty appointment for the Director of a new Center
which will concentrate on algorithms, complexity theory,
combinatorics, and related topics. Don tells me that the applicant
pool for an additional billet we are trying to fill is truly
outstanding. Stay tuned for developments in this subject during
Winter Quarter.
2) Besides the "theory" search, we are engaged in three others: one in
robotics, one in scientific computing, and one in "programming
languages." (In scientific computing, we were disappointed that
Roland Glowinski decided not to accept our offer of a faculty
appointment.)
3) We have not yet secured a definite replacement for Stuart Reges as
Assistant Chairman of Educational Affairs. We hope to entice a
certain person, quite prominent in computer science education circles,
to come to Stanford as an Associate Professor (Teaching). (Of course,
this can only be done after Departmental, School, and Provostial
approval. The process of securing such approval awaits further
"background work.") In the meantime, as I mentioned earlier, we are
extremely fortunate to have Roy Jones as Acting Asst. Chairman.
4) At the moment we have no plans to solve problems caused by
departures of faculty in AI (Paul Rosenbloom and Bruce Buchanan).
Paul and Bruce worked very effectively with graduate students and were
involved in research projects of great importance. Since Paul was an
"unbilleted" professor, we would need a brand new billet to replace
him. And Bruce is technically on leave (we all hope he comes back);
if he decides to stay at Pittsburgh, I presume we will be able to
search for a new Professor (Research). In the meantime, their areas
of expertise are areas that we cannot offer our students.
5) We have a number of concerns affecting students. The PhD students
feel (rightly, I think) that they are not getting enough contact with
some of our faculty. They also feel that although they serve on a
number of departmental committees, decisions are sometimes made
without sufficient consultation. Along with the junior faculty, our
students are extremely important to the Department. I want their
morale to be high (at least as high as morale can be among those from
whom we expect a great deal of hard work). I want them to be able to
say of their Stanford experience that it was outstanding and to be
able to recommend Stanford enthusiastically to prospective students.
During the past few weeks there has been a lot of e-mail discussion
about our PhD program---about the respective roles of research,
breadth education, and the comps. Ed Feigenbaum mentioned that he
thought this topic was one of the most important facing the Department
at this time. I agree. We'll all get into this in great detail during
the coming quarter, and I'd like to see if a consensus on the matter
can be reached.
Our Masters students sometimes feel that they are left out of the life
of the Department. We take their money (or their company's money),
teach them courses, and that's it. We need to find a way to make them
feel more a part of Stanford while they are here.
We aren't very good yet at interacting with our undergraduate majors.
Since the program is new, it is to be expected that we are still
learning, but I'd be interested in suggestions about how we can
improve.
Enough of the accomplishents/challenges business. People will recall
also that the Department had its first external "visiting committee"
in a while. They helped increase our awareness of some of the very
challenges that I have just mentioned. I am all for visiting committees
and hope that they will return late in this calendar year to look us
over again. (They told me that they wanted to see some of our
problems solved by then, so I have a big year ahead of me!)
In October I assembled a standing committee of faculty members to
serve as "spokespeople" for the four major areas of the Department
(John Hennessy, Systems; Jean-Claude Latombe, AI/Robotics; Joe Oliger,
Scientific Computing; and John Mitchell, Theory). We meet every
couple of weeks (along with the Senior Staff and the student
representatives). I expect to use this group even more during the
coming year to help run the Department.
If we all had infinite time, patience, and energy to deliver them,
here are some of the things I would wish for next year:
1) Increased financial contributions from our alumni and friends
to get our building campaign going.
2) More intellectual interaction among the faculty (instead of
each one being an island).
3) More wide-spread realization on the part of the faculty that life
at a university is more than one's own individual research; it also
involves substantial effort on teaching, on advising students, helping
with committees, thinking about the future of the Department, and
mentoring the junior faculty.
4) A greater tendency on the part of all of us (students too!) to
assume that the people with whom we deal have good will and are "with
us" rather than "against us." (I don't think computer bboard
communications would be very interesting if everyone granted me this
wish.) I imagine a scale at one end of which is extreme paranoia---a
conviction that others are plotting against us. At the other end of
this scale is the conviction that no one could possibly ever want to
do us harm; in extreme form that's probably also an unrealistic and
unhealthy belief. But I would like, nevertheless, to urge us a bit
more toward that naive end of the scale because beliefs all along the
scale tend to be somewhat self-fulfilling.
Realizing that our energies, time, and patience are finite, I close
by wishing you all the best for 1989 and asking simply that you
do what you can in granting my wishes.
Cordially,
Nils
∂03-Jan-89 0832 @Score.Stanford.EDU:chandler@polya.Stanford.EDU First Faculty Lunch....Winter Quarter
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Jan 89 08:32:09 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 3 Jan 89 08:28:54-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA19376; Tue, 3 Jan 89 08:23:10 PDT
Date: Tue, 3 Jan 1989 8:23:08 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, bureaucrats@score
Subject: First Faculty Lunch....Winter Quarter
Message-Id: <CMM.0.87.599847788.chandler@polya.stanford.edu>
An early reminder......the first faculty lunch for the Winter Quarter will be
held in the Hartley Conference Room (Mitchell Earth Science Building) next
Tuesday, 1/10. Rebecca Lasher from the Math/CSD Library will be dicsussing
and demonstrating online access to library materials.
∂03-Jan-89 1027 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Recursion Theorems, a question on litterature.
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Jan 89 10:27:04 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA23504; Tue, 3 Jan 89 10:26:25 PDT
Message-Id: <8901031826.AA23504@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 3 Jan 89 10:26:42 PST
Received: by BYUADMIN (Mailer R2.01A) id 7060; Tue, 03 Jan 89 11:24:29 MST
Date: Tue, 3 Jan 89 10:57:09 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Jesper L. Traff" <traff%DIKU.DK@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Jesper L. Traff" <traff%DIKU.DK@Forsythe.Stanford.EDU>
Subject: Recursion Theorems, a question on litterature.
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
In a book by James S. Royer: "A connotational Theory of program
structure" (Springer, LNCS 273) there is a rather incomplete reference
to a paper by John Case: "Self reflection in machines I: applications
of recursion theorems", 1988, apparently a techincal paper from State
University of New York at Buffalo. I'm very interested in this topic
(as a student project at DIKU we have done some experiments with
implementations of both Kleene's and Rogers' 2nd recursion theorems,
"culminating" in a language wherein fixed-points can be expressed very
directly. However, "practical" applications of these theorems are
few), so therefore I ask whether there is anybody on the net who knows
that paper (and can send me either a copy or a more complete
reference) - or litterature containing applications other than the
classical ones (e.g. self-reproducing programs, elimination of recursion
etc.).
Thanks in advance
Jesper Larsson Traff
DIKU, Dept. of Computer Sceince, University of Copenhagen
Denmark
e-mail: traff@diku.dk
∂03-Jan-89 1031 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Second Call for Papers
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Jan 89 10:31:50 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA23796; Tue, 3 Jan 89 10:31:16 PDT
Message-Id: <8901031831.AA23796@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 3 Jan 89 10:31:34 PST
Received: by BYUADMIN (Mailer R2.01A) id 7128; Tue, 03 Jan 89 11:26:20 MST
Date: Tue, 3 Jan 89 11:00:50 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Kerny McLaughlin <kerny%CS.COLUMBIA.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Kerny McLaughlin <kerny%CS.COLUMBIA.EDU@Forsythe.Stanford.EDU>
Subject: Second Call for Papers
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
SECOND CALL FOR PAPERS
Third Symposium on Complexity of Approximately Solved Problems
Computer Science Department
Columbia University
April 3-5, 1989
PROGRAM COMMITTEE:
Kenneth Arrow
Department of Economics
Stanford University
Stanford, California
Jerome Feldman
International Computer Science Institute
147 Center Street
Berkeley, California
Richard Karp
Computer Science Department
University of California at Berkeley
Berkeley, California
Christos Papadimitriou
Computer Science Department
University of California at San Diego
San Diego, California
Steven Smale
Mathematics Department
University of California at Berkeley
Berkeley, California
Joseph Traub
Computer Science Department
Columbia University
New York, New York
Henryk Wozniakowski
Computer Science Department
Columbia University
New York, New York
Donald Ylvisaker
Statistics Department
University of California at Los Angeles
Los Angeles, California
PARTIAL LIST OF SPEAKERS
PLENARY SPEAKERS:
Leon N. Cooper
Brown University
Steven Smale
University of California, Berkeley
INVITED SPEAKERS:
Adam Bojanczyk
Cornell University
Terrance Boult
Columbia University
David Donoho
University of California, Berkeley
Zvi Galil
Columbia University
Feng Gao
University of British Columbia
Ehud Kalai
Northwestern University
Mark Kon
Boston University
Marek A. Kowalski
University of Warsaw
J. Kuczynski
University of Warsaw
David Lee
AT&T Bell Laboratories
Leonid Levin
Boston University
Mario Milanese
Politecnico di Torino
Erich Novak
University of Erlangen
Michael Shub
IBM, T.J. Watson Research Center
K. Sikorski
University of Utah
Michael Steele
Princeton University
Aleksei Sukharev
Moscow State University
John N. Tsitsiklis
Massachusetts Institute of Technology
Umesh Vazirani
University of California, Berkeley
Grace Wahba
University of Wisconsin
Greg Wasilkowski
University of Kentucky
Arthur Werschulz
Columbia University
Henryk Wozniakowski
Columbia University
SOME OF THE TOPICS TO BE ADDRESSED ARE:
Average Case Analysis of Algorithms Neural Nets
Computational Complexity Optimal Recovery
Computer Vision Parallel Computation
Connectionist Models Prediction and Estimation
Continuous Complexity Random Algorithms
Decision Theory Random Complexity
Design of Experiment Robotics
Distributed Complexity Scientific Computation
Information-Based Complexity Seismology
Inverse Problems Signal Processing
Mathematical Economics
CONTRIBUTED PAPERS: All appropriate papers for which abstracts are
contributed will be scheduled. Contributed papers will be twenty
minutes in length.
To contribute a paper send title, author, affiliation, and abstract on
a single 8 1/2 by 11 sheet of paper or by electronic mail.
The above can be sent by U.S. mail to:
J.F. Traub
Computer Science Department
Columbia University
450 Computer Science Building
New York, New York 10027
Electronic Mail: kerny@cs.columbia.edu
TITLES AND ABSTRACTS MUST BE RECEIVED BY NO LATER THAN FEBRUARY 1, 1989
PUBLICATION: Invited papers will be published in the Journal of Complexity.
REGISTRATION: The symposium will be held in the Kellogg Conference
Center, on the fifteenth floor of the International Affairs Building,
Columbia University, 118th Street and Amsterdam Avenue. Registration
will start at 9:00 a.m. THERE IS NO REGISTRATION CHARGE.
FOR FURTHER INFORMATION: The program schedule will be sent
electronically about March 1, 1989. If you have any questions,
contact Kerny McLaughlin, Computer Science Department, Columbia
University, (212) 854-2736.
To help us plan the symposium please complete the information
below and return by U.S. Mail to Traub or by electronic mail to
kerny@cs.columbia.edu.
-------------------------------------------
SYMPOSIUM ON COMPLEXITY OF APPROXIMATELY SOLVED PROBLEMS
April 3-5, 1989
Name:
Affiliation:
Address:
[ ] I will attend the Complexity Symposium.
[ ] I may attend the Complexity Symposium.
[ ] I will contribute a paper.
∂03-Jan-89 1038 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Call for Papers
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Jan 89 10:37:55 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA24018; Tue, 3 Jan 89 10:37:08 PDT
Message-Id: <8901031837.AA24018@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 3 Jan 89 10:37:23 PST
Received: by BYUADMIN (Mailer R2.01A) id 7433; Tue, 03 Jan 89 11:34:10 MST
Date: Tue, 3 Jan 89 12:09:17 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
From: THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu
Subject: Call for Papers
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Call for Papers
Discrete Applied Mathematics
Special issue on connections between Logic and combinatorial topics
with emphasis on probabilistic aspects
and bounding the length of proofs
Topics of interest include, but are not limited to:
1. Resource Bounded Proof Theory
a. Upper and/or lower bounds on the number of steps
required by proofs in some logic system.
b. Probabilistic upper and/or lower bounds on the number of steps
required to prove random instances.
c. Poperties of families of instances with a limit on the
number of times an assumption may be used, or on the
number of different bound variables allowed.
d. Probabilistic analysis of algorithms for the satisfiability
problem.
2. Comparison of Systems/Problems
a. Proofs in logic system A are much shorter than proofs in
logic system B (almost always).
b. Proofs of tautology must be at least some amount longer
than proofs of satisfaction (almost always).
c. Why are certain combinatorial theorems unprovable in certain
formal systems?
d. Relationship between unprovability and combinatorial
properties of instances.
3. Other Topics
a. Logical aspects of circuit-based complexity models.
b. Group theoretic invariance of Boolean functions, with
connections to parallel complexity.
c. Computability over the real number system, applied to
develop complexity measures for numerical algorithms.
d. 0-1 laws for first order and higher order logics on
finite graphs and other combinatorial structures.
To assure consideration, please submit three copies of your manuscript
to one of the editors below before August 1, 1989:
J. Michael Dunn John V. Franco William H. Wheeler
Dept. of Philosophy Computer Science Dept. Dept. of Mathematics
Indiana University Indiana University Indiana University
Bloomington, IN 47405 Bloomington, IN 47405 Bloomington, IN 47405
∂03-Jan-89 1228 X3J13-mailer Hawaii registration status
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 3 Jan 89 12:27:56 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA03395g; Tue, 3 Jan 89 12:24:09 PST
Received: by challenger id AA07960g; Tue, 3 Jan 89 12:20:10 PST
Date: Tue, 3 Jan 89 12:20:10 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8901032020.AA07960@challenger>
To: x3j13@sail.stanford.edu
Subject: Hawaii registration status
Please let me know if you have any changes.
---jan---
X3J13 Attendee Information
01/03/89
Name Institute Paid L1 L2 L3 Luau
Jim Antonisse MITRE Corp. 113.50 y y y 1
Bill Arbaugh U.S. Army -0- y y y -
Kim Barrett Integrated Inference 113.50 y y y 1
David Bartley Texas Instruments $75.00 y y y -
Paul Beiser HP -0- y y y -
Skona Brittan Microcomputer Systems -0- y y y -
Jerome Chailloix ILOG -0- y y y -
Kathy Chapman DEC -0- y y y 2
Jeff Dalton University of Edinburgh -0- y y y 1
Jerry Duggen HP -0- y y y 2
Patrick Dussud Lucid, Inc. -0- y y y 1
Dick Gabriel Lucid, Inc. -0- y y y 3
George Hadden Honeywell -0- y y y 2
Jim Kempf SUN Microsytsems -0- y y y 1
Gregor Kiczales Xerox Corp. -0- y y y 1
Aaron Larson Honeywell -0- y y y 2
Kevin Layer Franz, Inc. $75.00 y y y 1
Thom Linden IBM $75.00 y y y 3
David Loeffler MCC 113.50 y y y 1
Sandra Loosemore University of Utah -0- y y y -
Barry Margolin Thinking Machines, Inc. 113.50 y y y y
Larry Masinter Xerox $75.00 y y y 1
Robert Mathis CONTEL -0- y y y 4
David Moon Symbolics, Inc. -0- 1 1 1 -
Greg Nuyens ILOG -0- y y y -
Chris Perdue SUN MicroSystems -0- y y y 1
Dan Pierson Encore Computer -0- y y y 1
Jeff Rosenking Grumman Corp. -0- y y y -
Paul Tucker IBM -0- y y y 2
David Unietis Lucid, Inc. -0- y y y 1
Mary Van Deusen IBM -0- y y y -
Ellen Waldrum TI $75.00 y y y 2
JonL White Lucid, Inc. -0- y y y 1
Gail Zacharias Coral Software Corp. -0- y y y 2
Jan Zubkoff Lucid, Inc. -0- y y y 2
∂03-Jan-89 1324 X3J13-mailer issues from cl-compiler
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Jan 89 13:24:43 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA27137; Tue, 3 Jan 89 14:23:35 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA05977; Tue, 3 Jan 89 14:23:33 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901032123.AA05977@defun.utah.edu>
Date: Tue, 3 Jan 89 14:23:32 MST
Subject: issues from cl-compiler
To: x3j13@sail.stanford.edu
I will be sending out a number of issues from the compiler committee
over the next several days. We plan to discuss these at the upcoming
meeting and vote on any that appear to be noncontroversial. Some of
the issues are marked **DRAFT**; these are issues that we do not feel
have had enough consideration to be voted upon yet, but where we would
like to get feedback from a larger group.
Please send comments on these issues to cl-compiler@sail.stanford.edu
(-not- to the X3J13 mailing list). Alternatively, we will consider
amendments at the upcoming meeting. (Having your amendment written
down in advance will help considerably in reducing confusion.)
-Sandra
-------
∂03-Jan-89 1358 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu DARPA Announcement
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Jan 89 13:58:50 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 3 Jan 89 13:55:51-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA06061; Tue, 3 Jan 89 13:52:08 PDT
Date: Tue, 3 Jan 89 13:52:08 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8901032152.AA06061@Tenaya.stanford.edu>
To: faculty@score
Subject: DARPA Announcement
For your information:
-------
Return-Path: <SSMITH@KL.SRI.COM>
Received: from KL.SRI.COM by Warbucks.AI.SRI.COM with INTERNET ;
Tue, 3 Jan 89 07:10:02 PST
Date: Tue, 3 Jan 89 07:03:02 PST
From: Sue Smith <SSMITH@KL.SRI.COM>
Subject: BAA - ISTO
To: DARPA-DB@KL.SRI.COM
Message-ID: <12459606567.10.SSMITH@KL.SRI.COM>
DARPA-DB: .BAA.BIDS.ISTO.
COMMERCE BUSINESS DAILY
DECEMBER 28, 1988
ISSUE: PSA-9746
BROAD AGENCY ANNOUNCEMENT (BAA#89-05): RESEARCH IN INFORMATION AND SCIENCE
AND TECHNOLOGY SOL BAA#89-05 DUE 043089 POC R. H. Register, (Contracts),
(202)694-1771; MAJ J. Mark Pullen, USA, (Technical), (202)694-5051.
Advanced Computing Systems. The Defense Advanced Research Projects Agency
(DARPA) is soliciting proposals for research in the area of information
science and technology in support of the DARPA Basic Research Program and
the DARPA Stragetic Computing program. Proposed research should investigate
innovative approaches and techniques that lead to or enable revolutionary
advances in the state of the art. Specifically excluded is research which
primarily results in evolutionary improvement to the existing state of
practice. When appropriate, new concepts are to be demonstrated by means of
systems prototypes. Topics to be considered include, but are not limited to
parallel computing architectures; microsystem design and prototyping;
software technology research; networking/command, control and
communications; machine intelligence; and manufacturing technology. General
Guidelines. Unless the nature of the research precludes such, the work is
expected to produce experimental prototypes that can be distributed to the
research community for evaluation and use. This will normally require the
delivery of products such as prototype software and/or hardware, designs,
and other associated systems that embody results of the research. Proposals
must provide specific details concerning technology transition, both within
the research community and into industrial application. In order to
encourage and facilitate technology transfer, software and systems
interfaces should be designed to anticipate future standards. All prototype
deliverables should be documented appropriately, and examples and tutorial
material should be provided when necessary. Sources for research will be
selected by a formal technical/scientific/business decision process.
Individual proposal evaluations will be based on acceptability or
unacceptability without regard to other proposals submitted under the
announcement. Evaluation of proposals will be performed using the following
criteria which are listed in order of priority: quality, relevan{e, and
personnel; related experience and capability; cost. Principal funding for
proposals selected under this announcement will begin in Fiscal Year 1990
with some modest initial efforts in Fiscal Year 1989. It is anticipated
that at least twenty million dollars in funding will be available to
support proposals in this area for Fiscal Year 1990. However, proposals
will be evaluated within technical program areas and must compete for
limited funds available in those areas. Proposals submitted may be
evaluated as they are received, or they may be collected and reviewed
periodically. Prospective proposers are encouraged to submit a proposal
abstract not later than January 30, 1989. DARPA/ISTO intends to respond to
such abstracts within 30 days of receipt, providing an assessment of the
likely viability of a full proposal. This procedure is intended to minimize
unnecessary effort in proposal preparation and review, and is not a
requirement {or submission or selection of proposals. Proposals can range
from small-scale efforts that are primarily theoretical in nature, to
medium-scale experimental and prototyping efforts of hardware and/or
software, to larger-scale integrated systems efforts which include
industrial cooperation and cost sharing. This announcement will remain in
effect until April 30, 1989. The complete Broad Agency Announcement,
including required formats for full and abstract proposals and other
pertinent details, can be obtained by written request to: DARPA/ISTO (ATTN:
BAA #89-05), 1400 Wilson Blvd., Arlington, VA 22209-2308. Telephonic
requests for this announcement will not be accepted. Inquiries of a
contractual nature may be directed to Ron H. Register at (202) 694-1771.
SPONSOR: Defense Advanced Research Projects Agency (DARPA), Contracts
Management (CMO), 1400 Wilson Blvd., Arlington, VA 22209-2308
-------
-------
∂03-Jan-89 1406 @Score.Stanford.EDU:bhayes@polya.Stanford.EDU Re: DARPA Announcement
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Jan 89 14:06:43 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 3 Jan 89 14:04:06-PST
Received: from LOCALHOST by polya.Stanford.EDU (5.59/25-eef) id AA01070; Tue, 3 Jan 89 14:04:49 PDT
Message-Id: <8901032204.AA01070@polya.Stanford.EDU>
To: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Cc: faculty@score
Subject: Re: DARPA Announcement
In-Reply-To: Your message of Tue, 03 Jan 89 13:52:08 -0700.
<8901032152.AA06061@Tenaya.stanford.edu>
Date: Tue, 03 Jan 89 14:04:47 -0800
From: bhayes@polya.Stanford.EDU
Perhaps I can get a grant to study the death of the paragraph.
∂03-Jan-89 1424 X3J13-mailer issue ALLOW-LOCAL-INLINE
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Jan 89 14:24:12 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA00523; Tue, 3 Jan 89 15:23:04 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA06032; Tue, 3 Jan 89 15:23:02 MST
Date: Tue, 3 Jan 89 15:23:02 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901032223.AA06032@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: issue ALLOW-LOCAL-INLINE
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: ALLOW-LOCAL-INLINE
References: CLtL p. 156, 159
Related issues: PROCLAIM-INLINE-WHERE
Category: CLARIFICATION
Edit History: 21 Sept. 88 V1 by David Gray
27 Oct. 88 V2 by David Gray - new proposal
9 Nov. 88 V3 by David Gray - expanded problem
description and discussion sections.
30 Dec. 88 V4 by Sandra Loosemore -- suggestions from Pitman
Problem Description:
The proposal PROCLAIM-INLINE-WHERE:BEFORE (which was accepted by X3J13
on 10/12/88) clarifies the use of INLINE proclamations, but there
remains a similar problem with the use of a local (DECLARE (INLINE
...)): how can the compiler expand the function inline if it didn't
know that the necessary information should have been saved when the
function was compiled?
Note that an INLINE proclamation does two things:
(1) It tells the compiler to do extra things when it sees the
function -definition-, to make it possible to code the function
inline.
(2) It tells the compiler to code -calls- to the function inline.
In order for local INLINE declarations to be useful, we need part 1
without part 2.
Proposal ALLOW-LOCAL-INLINE:INLINE-NOTINLINE
Clarify that to define a function FOO which is not INLINE by default
but for which (DECLARE (INLINE FOO)) will make FOO be locally inlined,
the proper definition sequence is:
(PROCLAIM '(INLINE foo))
(DEFUN foo ...)
(PROCLAIM '(NOTINLINE foo))
The INLINE proclamation preceding the DEFUN ensures that compiler will
save the information necessary for inline expansion, and the NOTINLINE
proclamation following the DEFUN prevents it from being expanded
inline everywhere.
Note that while implementations are never required to perform inline
expansion of function calls, many implementations that do support
inline expansion will not be able to respond to local INLINE requests
if this technique is not followed.
Rationale:
Local INLINE declarations are of little use without some way of
alerting the compiler to the possibility of inline expansion before
the function is compiled. This seems the simplest solution since it
just clarifies existing practice instead of adding a new feature to
the language.
A compiler could use some heuristic to save the definitions of functions
that are short enough to look like good candidates for inline expansion,
but then the user is never sure what to expect. It is possible that a
compiler could simply save all definitions (assuming availability
of adequate storage space) but we shouldn't require that.
Test Cases/Examples:
Given the following input to COMPILE-FILE, does F1 get expanded inline
in F2, and does F3 get expanded inline in F4?
(defun f1 (a) (+ a 100))
(defun f2 (b) (declare (inline f1)) (f1 b))
(proclaim '(inline f3))
(defun f3 (a) (+ a 100))
(proclaim '(notinline f3))
(defun f4 (b) (f3 b)) ;F3 is not inline.
(defun f5 (c) (declare (inline f3)) (f3 c)) ;F3 is locally inline.
(defun f6 (c) (f3 c)) ;The local effect is not
; persistent.
Current Practice:
In the example above, using Symbolics, Lucid, or Explorer, F1 is not
expanded in F2, but F3 is expanded in F5.
Cost to implementors:
None, since this is a clarification in accordance with current
practice.
Cost to users:
None.
Benefits:
Users will be able to use (DECLARE (INLINE ...)) with greater assurance
that it will really do something.
Costs of Non-Adoption:
Users will not know how to reliably request inline expansion on a
local basis. This technique is not obvious, and even the need
for it likely to be apparent only to people who understand something
about how the compiler does inline expansion.
Discussion:
Version 1 of this issue included proposal
ALLOW-LOCAL-INLINE:PROCLAIM-ALLOW-INLINE to make an addition to the
language:
(PROCLAIM '(ALLOW-INLINE foo))
This was met with a lack of enthusiasm since it was pointed out that
the same effect could be obtained by using a combination of INLINE and
NOTINLINE.
This is may not be completely true, however, since people's thinking
about NOTINLINE has evolved in the direction of a declaration that
tells the compiler "assume nothing about this function". Thus, a
NOTINLINE proclamation might suppress some optimizations that would
have occurred if there had never been an INLINE and NOTINLINE.
Ideally, it would be nice to have multiple levels of control instead
of just INLINE or NOTINLINE -- something like:
* always inline
* maybe inline (let the compiler decide)
* just save the definition for possible local inline
* default
* never inline
Pitman has said that he generally approves of the direction of this
proposal, but he has also expressed concerns about how the persistance
of INLINE proclamations may cause confusion when functions are redefined
in an incremental development environment.
∂03-Jan-89 1426 X3J13-mailer issue COMPILE-ENVIRONMENT-CONSISTENCY
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Jan 89 14:25:59 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA00548; Tue, 3 Jan 89 15:24:53 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA06035; Tue, 3 Jan 89 15:24:49 MST
Date: Tue, 3 Jan 89 15:24:49 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901032224.AA06035@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: COMPILE-ENVIRONMENT-CONSISTENCY
References: CLtL p. 68-69, 143, 321
RAM's "Compiler Cleanup Proposal #3"
Category: CLARIFICATION
Edit History: V1, 2 Sep 1988, Sandra Loosemore (initial draft)
V2, 9 Sep 1988, Sandra Loosemore (incorporate suggestions)
V3, 26 Oct 1988, Sandra Loosemore (add suggestion from Benson)
Problem Description:
CLtL does not clearly specify what aspects of the compiletime
environment the compiler (or other preprocessor) may "wire in" to code
being compiled.
Proposal COMPILE-ENVIRONMENT-CONSISTENCY:CLARIFY:
Common Lisp deliberately leaves unspecified the time at which certain
transformations, such as macro expansion, are performed within a
program. While some implementations perform such transformations
concurrently with evaluation, it is also legitimate to perform
transformations during a preprocessing phase. For example, an
implementation might choose to apply transformations at "function
promotion time" (i.e., transformations are applied once during
evaluation of a surrounding FUNCTION special form), or to completely
transform each top-level form and all of its subforms before
performing any evaluation. User programs cannot portably depend upon
either the time of such transformations, or the number of times the
transformations are applied.
In all cases, however, compiling a program (with COMPILE or
COMPILE-FILE) provides a mechanism for forcing these transformations
to be applied and a guarantee that, once compiled, no further
transformations will be applied to that program.
In the discussion that follows, the term "compiler" is to be understood
to include other preprocessors as well. Likewise, the "compiletime
environment" refers to the environment in which program transformations
occur, while "runtime" refers to the time the program is executed.
(1) The following information *must* be present in the compiletime
environment for the preprocessor to apply the correct transformations.
This information need not also be present in the runtime environment.
(a) Macro definitions must be available in the compiletime environment.
The compiler may assume that forms that are lists beginning with
a symbol that does not name a macro or special form is a function
call. (This implies that SETF methods must also be available at
compiletime.)
(b) Special variables must be declared as such before they are bound.
The compiler must treat any undeclared variable binding as a
lexical binding.
(2) The compiler *may* "wire in" the following kinds of information
into the code it produces, if the information is present in the
compiletime environment. However, since implementations are not
required to do this, user code must ensure that the information is
also defined consistently in the runtime environment. Except as
noted, the behavior of user programs is unspecified in situations
where the information is defined differently at runtime than at
compiletime, since the user cannot depend upon which will take
precedence in a particular implementation. In all cases, the absence
of the information at compiletime is not an error, but its presence
may enable the compiler to do a better job.
(a) The compiler may assume that functions that are defined and
declared INLINE in the compiletime environment will retain the
same definitions at runtime.
(b) The compiler may assume that, within a named function, a
recursive call to a function of the same name refers to the
same function, unless that function has been declared NOTINLINE.
(c) COMPILE-FILE may assume that, in the absence of NOTINLINE
declarations, a call within the file being compiled to a named
function which is defined in that file refers to that function.
(This permits "block compilation" of files.) The behavior of
the program is unspecified if functions are redefined individually
at runtime.
(d) The compiler may assume that the signature (or "contract") of
all built-in Common Lisp functions will not change. In addition,
the compiler may treat all built-in Common Lisp functions as if
they had been proclaimed INLINE.
(e) The compile may assume that the signature (or "contract") of
functions with FTYPE information available will not change. (See
issue FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS.)
(f) The compiler may "wire in" the values of symbolic constants
that have been defined with DEFCONSTANT in the compiletime
environment.
(g) Types that are defined with DEFTYPE or DEFSTRUCT can be assumed to
retain the same definition in the runtime environment as in the
compiletime environment. (Note that it is not an error for an
unknown type to appear in a declaration at compiletime, although
it is reasonable for the compiler to emit a warning in such a
case.)
(h) The compiler may assume that a class name defined by DEFCLASS
that is present in the compiletime environment will also be a
class name at runtime, and that class will be an instance of the
same metaclass. There may be additional conformance requirements
imposed by the metaclass, but there are none for STANDARD-CLASS.
(i) The compiler may assume that if type declarations are present
in the compiletime environment, the corresponding variables and
functions present in the runtime environment will actually be of
those types; otherwise, the behavior of the program is undefined.
(3) The compiler *must not* make any additional assumptions about
consistency between the compiletime and runtime environments. In
particular:
(a) The compiler may not assume that functions that are defined
in the compiletime environment will retain the either the
same definition or the same signature at runtime, except
in situations (2a) through (2e) above. It is, however,
reasonable for the compiler to emit warning messages about
calls to functions that are defined at compiletime, but where
the wrong number or type of arguments are supplied.
(b) The compiler may not signal an error if it sees a call to a
function that is not defined at compiletime, since that function
may be provided at runtime. Again, it is permissible to emit
a warning in these situations.
Rationale:
This proposal generally reflects current practice.
Current Practice:
I know of no compiler that does not implement the provisions of item (1).
For item (2), most compilers (including Lucid) optimize self-recursive
calls by default. Most compilers also opencode data structure
accessors (such as CAR) at some level of optimization, and some code
much more complicated built-in functions inline as well. VaxLisp, for
example, normally compiles MEMBER inline. The Lucid compiler makes
use of type declarations to perform generic-to-specific
transformations on many arithmetic and sequence functions, which is
also a form of inlining. KCL performs block compilation by default,
and Lucid does so under certain conditions.
Cost to implementors:
Unknown, but probably minor.
Cost to users:
Since most implementations appear to be largely in conformance with the
proposal, users should notice little difference.
Benefits:
The presence of a definite specification of what may happen when will
help users structure their programs so they will compile correctly in
all Common Lisp implementations.
Discussion:
Most of the discussion on this issue has been centered on the
terminology describing error situations for item (2). In most cases
where there is an inconsistency between compile-time and run-time, the
results will be unpredictable but harmless. The major exception is
violation of type declarations, which is a "crash-and-burn" error in
many implementations.
There has also been some concern raised that item (3) would prohibit
such things as a cross-compiler that produces standalone programs in
an environment that disallows redefinition of functions. The intent
of this proposal is not to prohibit a compiler from having a magic
switch that imposes additional restrictions on the programs it
compiles, but such a compiler would not be a compiler for Common Lisp.
∂03-Jan-89 1428 X3J13-mailer issue DEFCONSTANT-SPECIAL
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Jan 89 14:28:00 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA00602; Tue, 3 Jan 89 15:26:55 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA06038; Tue, 3 Jan 89 15:26:53 MST
Date: Tue, 3 Jan 89 15:26:53 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901032226.AA06038@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: issue DEFCONSTANT-SPECIAL
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: DEFCONSTANT-SPECIAL
References: CLtL p. 68-69, 55-56
Issue DEFCONSTANT-NOT-WIRED
Issue PROCLAIM-LEXICAL
Issue SYNTACTIC-ENVIRONMENT-ACCESS
Issue SPECIAL-VARIABLE-TEST
Category: CLARIFICATION
Edit History: V1, 15 Nov 1988, Sandra Loosemore
V2, 22 Nov 1988, Sandra Loosemore
V3, 30 Dec 1988, Sandra Loosemore
Problem Description:
It is unclear whether DEFCONSTANT is supposed to proclaim the variable
SPECIAL. Page 56 says that symbols defined by DEFCONSTANT "may not be
further assigned to or bound". Page 69 says that "further assignment
to or binding of that special variable is an error" but permits
compilers to "choose to issue warnings about bindings of the lexical
variable of the same name". Does this mean that it is legal (but
perhaps only questionable style) to lexically rebind constants? If
so, this would seem to imply that they must not be proclaimed SPECIAL
(since CLtL provides no way to override a SPECIAL proclamation).
Some people think that DEFCONSTANT is supposed to proclaim the
variable SPECIAL because CLtL says that DEFVAR does, and that
DEFPARAMETER is like DEFVAR, and DEFCONSTANT is like DEFPARAMETER.
Also, the use of the phrase "that special variable" rather than "the
special variable of the same name" might indicate that the variable
really is supposed to be special.
Proposal DEFCONSTANT-SPECIAL:NO:
Clarify that DEFCONSTANT does not proclaim the variable special, but
that it is an error to rebind constant symbols as either lexical or
special variables. (In other words, a reference to a symbol declared
with DEFCONSTANT always refers to its global value.)
Rationale:
If DEFCONSTANT declared the variable special, the lexical rebindings
mentioned on p. 69 could never arise. Clarifying that lexical
rebinding (as well as special rebinding) of constants "is an error"
seems to be the behavior that most users expect. One serious problem
that might arise from allowing constants to be rebound lexically is
that it would not be reliable to include symbolic constants in macro
expansions, because the user might have rebound them to something
else.
Current Practice:
Most implementations apparently proclaim the variable special anyway.
Cost to implementors:
Minor.
Cost to users:
Probably none. Since many implementations do proclaim the variable to
be special (while at the same time forbidding special binding), there
is probably no user code that depends upon lexical rebinding of
DEFCONSTANTs.
Benefits:
An area of confusion in the language is removed.
Discussion:
This issue is primarily a documentation clarification. It arose
during a discussion of what the DEFCONSTANT macro might expand into.
As far as users are concerned, it makes no difference whether
constants are special or lexical, as long as all rebinding is
prohibited. The only situation where the distinction might become
important is if a function is added to the language to test whether a
variable has been proclaimed special.
The "problem description" section of the writeup on issue
PROCLAIM-LEXICAL (version 8) also appears to assume that constants
declared with DEFCONSTANT are not special.
∂03-Jan-89 1429 X3J13-mailer issue LOAD-TIME-EVAL
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Jan 89 14:29:40 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA00654; Tue, 3 Jan 89 15:28:33 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA06041; Tue, 3 Jan 89 15:28:30 MST
Date: Tue, 3 Jan 89 15:28:30 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901032228.AA06041@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: issue LOAD-TIME-EVAL
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: LOAD-TIME-EVAL
References: #, (p. 356), (EVAL-WHEN (LOAD) ...) (p. 69-70)
issue SHARP-COMMA-CONFUSION
Category: ADDITION
Edit history: 06-Jun-87, Version 1 by James Kempf
17-Jul-87, Version 2 by James Kempf
12-Nov-87, Version 3 by Pitman (alternate direction)
01-Feb-88, Version 4 by Moon
(from version 2 w/ edits suggested by Masinter)
06-Jun-88, Version 5 by Pitman
(fairly major overhaul, merging versions 3 and 4)
21-Sep-88, Version 6 by Moon (stripped down)
17-Oct-88, Version 7 by Loosemore (change direction again)
30-Dec-88, Version 8 by Loosemore (tweaks)
Problem description:
Common Lisp provides reader syntax (#,) which allows the programmer
to designate that a particular expression within a program is to be
evaluated early (at load time) but to later be treated as a constant.
Unfortunately, no access to this capability is available to programs
which construct other programs without going through the reader.
Some computations can be deferred until load time by use of EVAL-WHEN,
but since EVAL-WHEN must occur only at toplevel, and since the nesting
behavior of EVAL-WHEN is quite unintuitive, EVAL-WHEN is not a general
solution to the problem of load-time computation of program constants.
Proposal (LOAD-TIME-EVAL:R**2-NEW-SPECIAL-FORM):
Add a new special form, LOAD-TIME-VALUE, which has the following
contract:
LOAD-TIME-VALUE form &optional read-only-p [Special Form]
LOAD-TIME-VALUE provides a mechanism for delaying evaluation of <form>
until the expression is in the "runtime" environment.
If a LOAD-TIME-VALUE expression is seen by COMPILE-FILE, the compiler
performs normal semantic processing such as macro expansion but
arranges for the evaluation of <form> to occur at load time in a null
lexical environment, with the result of this evaluation then being
treated as an immediate quantity at run time. It is guaranteed that
the evaluation of <form> will take place only once when the file is
loaded, but the order of evaluation with respect to the "evaluation"
of top-level forms in the file is unspecified.
If a LOAD-TIME-VALUE expression appears within a function compiled
with COMPILE, the <form> is evaluated at compile time in a null lexical
environment. The result of this compile-time evaluation is treated as
an immediate quantity in the compiled code.
In interpreted code, (LOAD-TIME-VALUE <form>) is equivalent to (VALUES
(EVAL (QUOTE <form>))). Implementations which implicitly compile
(or partially compile) expressions passed to EVAL may evaluate the
<form> only once, at the time this compilation is performed. This is
intentionally similar to the freedom which implementations are given
for the time of expanding macros in interpreted code.
Note that, in interpreted code, there is no guarantee as to when
evaluation of <form> will take place, or the number of times the
evaluation will be performed. Since successive evaluations of the
same LOAD-TIME-VALUE expression may or may not result in an evaluation
which returns a "fresh" object, destructive side-effects to the
resulting object may or may not persist from one evaluation to the
next. It is safest to explicitly initialize the object returned by
LOAD-TIME-VALUE, if it is later modified destructively.
Implementations must guarantee that each reference to a
LOAD-TIME-VALUE expression results in at least one evaluation of its
nested <form>. For example,
(CONS #1=(LOAD-TIME-VALUE (COMPUTE-IT)) #1#)
must perform two calls to COMPUTE-IT; although there is only one
unique LOAD-TIME-VALUE expression, there are two distinct references
to it.
In the case of a LOAD-TIME-VALUE form appearing in a quoted expression
passed to EVAL, each call to EVAL must result in a new evaluation of
<form>. For example,
(DEFVAR X 0)
(DEFUN FOO () (EVAL '(LOAD-TIME-VALUE (INCF X))))
is guaranteed to increment X each time FOO is called, while
(DEFUN FOO () (LOAD-TIME-VALUE (INCF X)))
may cause X to be evaluated only once.
The READ-ONLY-P argument designates whether the result can be considered
read-only constant. If NIL (the default), the result must be considered
ordinary, modifiable data. If T, the result is a read-only quantity
which may, as appropriate, be copied into read-only space and/or shared
with other programs. (Because this is a special form, this argument is
-not- evaluated and only the literal symbols T and NIL are permitted.)
Rationale:
LOAD-TIME-VALUE is a special form rather than a function or macro
because it requires special handling by the compiler.
Requiring the compiler to perform semantic processing such as macro
expansion on the nested <form>, rather than delaying all such processing
until load time, has the advantages that fewer macro libraries may need
to be available at load time, and that loading may be faster and result
in less consing due to macroexpansion. If users really want to delay
macroexpansion to load time, this can be done with an explicit call to
EVAL, e.g.
(LOAD-TIME-VALUE (EVAL '(MY-MACRO)))
Allowing the same LOAD-TIME-VALUE to cause its nested <form> to be
evaluated more than once makes simplifies its implementation in
interpreters which do not perform a preprocessing code walk. It also
makes the rules for the time of its processing analogous to those
for macro expansion.
This proposal explicitly does -not- tie LOAD-TIME-VALUE to the #,
read macro. Doing so would be an incompatible change to the definition
of #, (which is reliably useful only -inside- quoted structure,
while LOAD-TIME-VALUE must appear -outside- quoted structure in a
for-evaluation position).
The requirement that LOAD-TIME-VALUE expressions be evaluated once per
reference (rather than once per unique expression) prevents problems
that could result by performing destructive side-effects on a value
that is unexpectedly referenced in more than one place.
Current Practice:
This is an addition to the language and has not yet been implemented.
Cost to Implementors:
In compiled code, (LOAD-TIME-VALUE <form>) is similar to
'#,<form>. Most implementations can probably make use of the same
mechanism they use to handle #, to handle LOAD-TIME-VALUE. Note that
#, does not currently provide a mechanism for dealing with
non-read-only-ness.
Implementing LOAD-TIME-VALUE in the interpreter should be fairly
straightforward, since one simply needs to evaluate the <form> in the
null lexical environment. Implementations that use a preprocessing
code walk in the interpreter to perform macro expansion could process
LOAD-TIME-VALUE forms at that time.
Some code-walkers would have to be taught about this new
special form. Such changes would likely be trivial.
Cost to Users:
Some code-walkers would have to be taught about this new
special form. Such changes would likely be trivial.
Benefits:
Users are given a mechanism that to force evaluation to be delayed
until load time that does not rely on a feature of the reader.
Discussion:
Earlier versions (up to version 7) of this proposal stated that
all semantic processing of the LOAD-TIME-VALUE form should be postponed
until load time.
The semantics of LOAD-TIME-VALUE would be simplified considerably if
the READ-ONLY-P argument were removed and destructive operations on
the result of evaluating <form> prohibited. However, some people feel
that the ability to destructively modify the value is an essential
feature to include.
"Collapsing" of multiple references to the same LOAD-TIME-VALUE
expression could be allowed for read-only situations, but it seems
like it would be more confusing to make it legal in some situations
and not in others.
A number of other alternatives have been considered on this issue,
including:
- A proposal for a new special form that would force evaluation of
the <form> to happen only once. This was rejected because of
implementation difficulties.
- A proposal to add a function making the "magic cookie" used by #,
available to user code. The current proposal does not prevent such
a function from being added, but this approach appeared to have
less support than making the hook available as a new special form.
- A proposal to remove #, entirely (issue SHARP-COMMA-CONFUSION).
- A suggestion to change the behavior of (EVAL-WHEN (LOAD) ...).
Kent Pitman says:
Although I'm willing to take multiple evaluation in the interpreter
as a compromise position, I would like it mentioned in the discussion
that this was only an expedient to getting this issue accepted at all,
and that I'm not really happy about it. I have said that I think a
number of our lingering problems (with EVAL-WHEN, COMPILER-LET, and
this -- for example) are due to the presence of interpreters which do
not do a semantic-prepass at a known time. If I had my way, we would
require a semantic pre-pass and we would then be able to forbid
multiple evaluations even in the interpreter.
∂03-Jan-89 1432 X3J13-mailer issue SHARP-COMMA-CONFUSION
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Jan 89 14:31:54 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA00762; Tue, 3 Jan 89 15:30:48 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA06046; Tue, 3 Jan 89 15:30:43 MST
Date: Tue, 3 Jan 89 15:30:43 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901032230.AA06046@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: issue SHARP-COMMA-CONFUSION
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: SHARP-COMMA-CONFUSION
References: CLtL p. 356
Issue LOAD-TIME-EVAL
Category: CHANGE
Edit History: V1, 17 Oct 1988, Sandra Loosemore
V2, 30 Dec 1988, Sandra Loosemore (comments from Pitman)
Problem Description:
The way the read macro #, is defined in CLtL does not make it clear
that it can only appear inside of (implicitly) quoted structure to
guarantee consistent handling between the interpreter and the
compiler. Examples of inconsistent uses would be #, forms appearing
outside of a QUOTE that expand into list or symbol forms that could be
interpreted as code, or strings that could be interpreted as
documentation strings. Users are even more likely to be confused
because the wording in CLtL compares the behavior of #, to the special
form EVAL-WHEN, which must appear in a for-evaluation position.
#, also presents a serious problem to program-analyzing programs
because evaluation is tied to the reader, rather than the interpreter
or compiler. In theory, this could be handled by altering the read table
to have #, construct a "magic cookie" instead of performing read-time
evaluation and having the code walker examine quoted structures, but I've
never seen this actually done in practice.
Proposal SHARP-COMMA-CONFUSION:REMOVE:
Remove the #, read macro from the language.
Rationale:
Removing #, is simpler than trying to redefine it. Removing it from
the standard, rather than redefining it to mean something else (see
issue LOAD-TIME-EVAL), would allow implementations to continue to
provide it as an extension. (Although CLtL does not appear to
explicitly address the question of whether implementations may extend
the reader syntax, some implementations already provide sharp-sign
read macros other than those described in CLtL, such as #P syntax for
pathnames.)
Current Practice:
#, is not used very frequently, but the functionality it provides is
important in some advanced applications; one such application that has
been cited is CLOS. Maintainers of such applications have generally
expressed a willingness to give up #, only if a suitable alternative
is offered (see issue LOAD-TIME-EVAL).
PSL/PCLS has never bothered to implement #, correctly (it's treated
just like #.), and nobody has ever complained about it being broken.
Cost to implementors:
None.
Cost to users:
Because #, is used so infrequently, most users would probably not even
notice its absence.
Issue LOAD-TIME-EVAL proposes to add a special form that would provide
a somewhat cleaner mechanism for load-time evaluation.
It is also possible to use a global variable to get the similar effect as
#,, although this is sometimes awkward and carries a space and
performance penalty in many implementations.
Benefits:
The language specification is simplified by removing a peculiar
feature of the language that is accessible only through the reader.
Removing #, may also allow simpler strategies for implementing
compiled file loaders to be used.
Discussion:
If this proposal is rejected, the definition of #, in the standard will
still need to be clarified to indicate that #, can only appear in
quoted structure. It should probably also include some mention of the
problems that #, can cause code walkers.
Kent Pitman says:
I approve of the ideas being discussed, but ONLY contingent on
LOAD-TIME-VALUE being introduced.
I am optimistic that LOAD-TIME-EVAL will pass, and so I don't think this
will keep #, from passing, but:
- I want people who vote for this to realize the importance of voting
for LOAD-TIME-EVAL.
- On the off chance LOAD-TIME-EVAL doesn't pass, I want people to have
been warned that the consequences were severe for some major
applications.
- I want the records to reflect the actual rationale people should and
hopefully will be using to make these decisions.
∂03-Jan-89 1604 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu cs300
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Jan 89 16:04:17 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 3 Jan 89 15:58:38-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA06171; Tue, 3 Jan 89 15:57:44 PDT
Date: Tue, 3 Jan 89 15:57:44 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8901032357.AA06171@Tenaya.stanford.edu>
To: faculty@score
Subject: cs300
Several faculty members and several first-year PhD students thought it
was a good idea to continue cs300 through Winter Quarter. However, no
one responded to my request for a volunteer to organize this
once-a-week (Thursday, 4:15-5:30) seminar series (in which CS and CSL
faculty describe their research to first-year PhD students). This is
curious in view of all of the e-mail discussion about the importance
of getting PhD students started in research. I could probably solve
the problem by simpling asking one of you to do it, but you all know
more than I if you have epsilon more time and energy to take on this
important and not-very-time consuming chore. (Barbara Hayes-Roth, with
Mike Genesereth's help, organized the series this past Fall Quarter.)
If no one responds to this note, I'm going to assume that collectively
we have decided not to offer this seminar during Winter Quarter.
-Nils
∂03-Jan-89 1618 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Visit to SUN Microsystems
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Jan 89 16:18:35 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 3 Jan 89 16:06:20-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA06186; Tue, 3 Jan 89 16:05:29 PDT
Date: Tue, 3 Jan 89 16:05:29 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8901040005.AA06186@Tenaya.stanford.edu>
To: faculty@score
Subject: Visit to SUN Microsystems
Sun Microsystems would like to enhance the possibilities for
collaboration with Stanford CS and CSL faculty. Toward that end, they
are willing to have a "Stanford CS Day" (or probably really half a
day) at SUN. SUN suggests that those faculty who would like to do so
could describe research that they are doing and that they think might
interest SUN. Faculty who are interested in participating should send
Joyce Chandler a note to that effect. (Note: this note is somewhat
different than the last one I sent about cs300. The present case has
no moral overtones; it isn't something I think we "should" do. If
enough faculty express interest, we'll do it.)
-Nils
∂03-Jan-89 1631 @Score.Stanford.EDU:chandler@polya.Stanford.EDU 1/10 Faculty Meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Jan 89 16:31:23 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 3 Jan 89 16:28:55-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA05428; Tue, 3 Jan 89 15:46:53 PDT
Date: Tue, 3 Jan 1989 15:46:44 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score
Subject: 1/10 Faculty Meeting
Message-Id: <CMM.0.87.599874404.chandler@polya.stanford.edu>
Just a reminder....the next general faculty meeting will be held in MJH-146
at 2:30 on January 10 (Tuesday). If you have any agenda items, please send
them to me as soon as possible.
Thanks and happy new year!
∂03-Jan-89 1719 LOGMTC-mailer Talk Thurs
Received: from ra.stanford.edu by SAIL.Stanford.EDU with TCP; 3 Jan 89 17:19:38 PST
Received: by ra.stanford.edu (5.59/25-eef) id AA02437; Tue, 3 Jan 89 17:18:17 PDT
Date: Tue, 3 Jan 89 17:18:17 PDT
From: John Mitchell <jcm@ra.stanford.edu>
Message-Id: <8901040118.AA02437@ra.stanford.edu>
To: ag@pepper, csd@score, daniel@mojave, linton@amadeus, logmtc@sail,
luca@src.dec.com, unger@amadeus, williams@ibm.com
Subject: Talk Thurs
Thurday 1/5 at 3 PM in MJH 301:
How To Make Ad-Hoc Polymorphsm Less Ad-Hoc
Phil Wadler
University of Glasgow
Abstract
Ad-hoc polymorphism allows operations like addition
or equality to be overloaded at several types
(e.g., + may stand for addition of integers or floats).
Languages like Standard ML and Miranda treat ad-hoc
polymorphism in an ad-hoc way. Type classes provide a
uniform framework for defining ad-hoc polymorphism and
provide a new approach to abstract data types and
object-oriented programming. They extend the Hindley/Milner
type system and generalize the "eqtype" variables of
Standard ML. Type classes are incorporated in the new
functional programming language Haskell.
∂04-Jan-89 0931 @Score.Stanford.EDU:tom@polya.Stanford.EDU heating problem
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Jan 89 09:31:32 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 4 Jan 89 09:28:53-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA23024; Wed, 4 Jan 89 09:07:11 PDT
Date: Wed, 4 Jan 89 09:07:11 PDT
From: Tom Dienstbier <tom@polya.Stanford.EDU>
Message-Id: <8901041707.AA23024@polya.Stanford.EDU>
To: csd@score, faculty@score
Subject: heating problem
I just talked to the folks in the know at the plumbing shop and the story
today is that the problem lies in the steam return. We do have steam, that
is used for heating and hot water generation, to the building but since the
return is clogged, there is no place for the steam to go.
We are not the only people without heat, apparently the whole quad is also
running cold.
tom
∂04-Jan-89 1043 LOGMTC-mailer Seminar in Logic
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Jan 89 10:43:49 PST
Received: by csli.Stanford.EDU (4.0/4.7); Wed, 4 Jan 89 10:42:20 PST
Date: Wed 4 Jan 89 10:42:19-PST
From: Sol Feferman <SF@CSLI.Stanford.EDU>
Subject: Seminar in Logic
To: logic@csli.Stanford.EDU
Message-Id: <599942539.0.SF@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
Seminar in Logic and Foundations
SPECIAL LECTURE:
Speaker: Prof. Gabriel Stolzenberg, Mathematics, Northeastern Univ.
Title: "A translation, impredicativity, rereading certain classical
arguments as constructive."
Time: Monday, January 9, 1989, 4:15-5:30 PM
Place: Room 381-T, Math Corner, Stanford
REGULAR SEMINAR MEETINGS:
Speaker: Paolo Mancosu
Title: "Generalizing classical and effective analogues for model theory"
Part III
Time: Tuesday, January 10, 1989, 4:15-5:30 PM
Place: (Same)
FUTURE SPEAKERS:
Michael Beeson, Yuri Gurevich, Itzhak Katznelson, Philip Scowcroft
(in some permuted order).
Participants are invited to give further talks (W,S).
NB:
There will be no meeting on Tuesday January 17, as a number of participants
will still be at the ASL meeting at UCLA. The regular seminar schedule
will resume on Tuesday, January 24. Note also change of regular meeting
days from Mondays to Tuesdays.
S. Feferman
-------
∂04-Jan-89 1049 @Score.Stanford.EDU:gio@sumex-aim.stanford.edu Re: DARPA Announcement
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Jan 89 10:49:35 PST
Received: from sumex-aim.stanford.edu by SCORE.STANFORD.EDU with TCP; Wed 4 Jan 89 10:46:54-PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA12044; Wed, 4 Jan 89 10:48:01 PST
Date: Wed, 4 Jan 1989 10:48:01 PST
From: Gio Wiederhold <gio@sumex-aim.stanford.edu>
To: Nils Nilsson <nilsson@tenaya.stanford.edu>
Cc: faculty@score.stanford.edu, bscott@score.stanford.edu,
ark@sail.stanford.edu, mendez@polya.stanford.edu
Subject: Re: DARPA Announcement
In-Reply-To: Your message of Tue, 3 Jan 89 13:52:08 PDT
Message-Id: <CMM.0.88.599942881.gio@sumex-aim.stanford.edu>
This announcement is intended to replace the Umbrella Contracts now in use
and is quite relevant for us.
Gio
∂04-Jan-89 1109 @Score.Stanford.EDU:tom@polya.Stanford.EDU DARPA Announcement
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Jan 89 11:09:06 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 4 Jan 89 11:06:12-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA26998; Wed, 4 Jan 89 11:06:48 PDT
Date: Wed, 4 Jan 89 11:06:48 PDT
From: Tom Dienstbier <tom@polya.Stanford.EDU>
Message-Id: <8901041906.AA26998@polya.Stanford.EDU>
To: gio@sumex-aim.stanford.edu
Cc: nilsson@tenaya.stanford.edu, faculty@score.stanford.edu,
bscott@score.stanford.edu, ark@sail.stanford.edu,
mendez@polya.stanford.edu
In-Reply-To: Gio Wiederhold's message of Wed, 4 Jan 1989 10:48:01 PST <CMM.0.88.599942881.gio@sumex-aim.stanford.edu>
Subject: DARPA Announcement
Ernst,,, those are prices per month.
tom
∂04-Jan-89 1115 @Score.Stanford.EDU:tom@polya.Stanford.EDU DARPA Announcement
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Jan 89 11:14:34 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 4 Jan 89 11:11:39-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA27295; Wed, 4 Jan 89 11:12:19 PDT
Date: Wed, 4 Jan 89 11:12:19 PDT
From: Tom Dienstbier <tom@polya.Stanford.EDU>
Message-Id: <8901041912.AA27295@polya.Stanford.EDU>
To: tom@polya.Stanford.EDU
Cc: gio@sumex-aim.stanford.edu, nilsson@tenaya.stanford.edu,
faculty@score.stanford.edu, bscott@score.stanford.edu,
ark@sail.stanford.edu, mendez@polya.stanford.edu
In-Reply-To: Tom Dienstbier's message of Wed, 4 Jan 89 11:06:48 PDT <8901041906.AA26998@polya.Stanford.EDU>
Subject: DARPA Announcement
Please disregard previous message.
tom
∂04-Jan-89 1412 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Theory Net
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Jan 89 14:12:00 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA05626; Wed, 4 Jan 89 14:10:29 PDT
Message-Id: <8901042210.AA05626@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Wed, 4 Jan 89 14:10:45 PST
Received: by BYUADMIN (Mailer R2.01A) id 8656; Wed, 04 Jan 89 15:08:46 MST
Date: Wed, 4 Jan 89 15:36:24 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Victor Miller -- moderator, Theory Net" <THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
From: "Victor Miller -- moderator, Theory Net" <THEORYNT%YKTVMX.BITNET@forsythe.stanford.edu>
Subject: Theory Net
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
I'll be out of town until January 12. I'll handle all of your contributions
when I get back. Meanwhile, as before, if you need to post something really
urgent, just start the subject with Urgent: and it will be automatically
distiributed to the list (provided that you send it to theorynt@vm1.nodak.edu
theorynt@dearn or theorynt@ndsuvm1 (the latter two on bitnet).
Victor
∂04-Jan-89 1428 @Score.Stanford.EDU:cheriton@Pescadero.Stanford.EDU Re: DARPA Announcement
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Jan 89 14:27:53 PST
Received: from Pescadero.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 4 Jan 89 14:25:15-PST
Received: by Pescadero.Stanford.EDU (5.59/25-eef) id AA17508; Wed, 4 Jan 89 14:28:07 PDT
Date: Wed, 4 Jan 89 14:28:07 PDT
From: David Cheriton <cheriton@Pescadero.Stanford.EDU>
Message-Id: <8901042228.AA17508@Pescadero.Stanford.EDU>
To: bscott@score, faculty@score
Subject: Re: DARPA Announcement
I dont understand Gio's comment. I think the BAA is purely to solicit
proposals. If they decide to fund a proposal, it might be funded
under the umbrellas contract as one task.
Or dont I understand?
∂04-Jan-89 1739 @Score.Stanford.EDU:gio@sumex-aim.stanford.edu Re: DARPA Announcement
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Jan 89 17:39:45 PST
Received: from sumex-aim.stanford.edu by SCORE.STANFORD.EDU with TCP; Wed 4 Jan 89 17:37:26-PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA24138; Wed, 4 Jan 89 17:38:33 PST
Date: Wed, 4 Jan 1989 17:38:31 PST
From: Gio Wiederhold <gio@sumex-aim.stanford.edu>
To: David Cheriton <cheriton@pescadero.stanford.edu>
Cc: bscott@score.stanford.edu, faculty@score.stanford.edu
Subject: Re: DARPA Announcement
In-Reply-To: Your message of Wed, 4 Jan 89 14:28:07 PDT
Message-Id: <CMM.0.88.599967511.gio@sumex-aim.stanford.edu>
I did not talk to Pullen directly when at DARPA, but my understanding was
that they are putting an alternative contract mechanism in place.
Responding to the BAA would qualify submitters and in that sense be similar
to an umbrella, but perhaps at a different level.
I will try to verify what is going on. Since the umbrella progress has
been extremely slow, I plan to follow up with a response if the BAA is
appropriate. Let me know if you want to kept informed. I do not think
that all of the faculty are interested in ARPA machinations.
Gio
∂04-Jan-89 2028 @Score.Stanford.EDU:DEK@SAIL.Stanford.EDU First Faculty Lunch --- Winter Quarter
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Jan 89 20:28:26 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 4 Jan 89 20:26:20-PST
Message-ID: <rwanX@SAIL.Stanford.EDU>
Date: 04 Jan 89 2027 PST
From: Don Knuth <DEK@SAIL.Stanford.EDU>
Subject: First Faculty Lunch --- Winter Quarter
To: faculty@Score.Stanford.EDU
I'd like to encourage everybody to come to this special lunch,
when Rebecca will be giving a demo I think must of you will find
quite interesting (it will probably change my own research habits
significantly). At last the databases available to us are getting
to be truly useful and not too expensive!
Reminder: This lunch will be in the Mitchell Earth Sciences Building
(opposite Durand and Terman), not in our usual location.
∂05-Jan-89 1055 debra@russell REMINDER
Received: from russell (Russell.Stanford.EDU) by SAIL.Stanford.EDU with TCP; 5 Jan 89 10:55:11 PST
Received: from localhost by russell (4.0/4.7); Thu, 5 Jan 89 10:56:40 PST
To: evesem@russell
Subject: REMINDER
Date: Thu, 05 Jan 89 10:56:39 PST
From: Debra Alty <debra@russell>
Please mark your calendars --
The next Evening Seminar Meeting will be Wednesday, January 11th @
7:30.
More details later.
Debra
∂05-Jan-89 1342 X3J13-mailer ISO discussion and X3J13 Agenda DRAFT
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 5 Jan 89 13:42:22 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA05813g; Thu, 5 Jan 89 13:38:32 PST
Received: by challenger id AA12199g; Thu, 5 Jan 89 13:34:30 PST
Date: Thu, 5 Jan 89 13:34:30 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8901052134.AA12199@challenger>
To: x3j13@sail.stanford.edu
Subject: ISO discussion and X3J13 Agenda DRAFT
Monday, January 16
8:00am - ISO discussion, Chart room
We've found copying facilities to be very expensive at hotels. We intend not
to use their facilities. Please mail copies of reports to Liz Anne's
attention at the hotel if you intend to distribute reports at the meeting.
Participants are encouraged to bring copies of reports mailed to them to the
meeting.
X3J13 Committee Meeting Agenda DRAFT
January 16 - 18, 1988
1 Call to Order, January 16, 9:00am Chart Room
2 Opening Remarks and Introductions
- Opening Remarks, Bob Mathis (10 minutes)
- Introduction of attendees
- Future meetings, Jan Zubkoff (5 minutes)
3 Approval of Agenda
4 Approval of Minutes
5 Other Business
6 Character Subcommittee Report, Thom Linden (2 hours)
7 Coffee Break 10:30
8 Character continuation
9 Chapter 3 CLOS, Gregor Kiczales (1 hour)
10 LUNCH 12:00 Voyage Room Restaurant
11 Compiler Subcommittee, Sandra Loosemore (2 hours)
12 Iteration Subcommittee Report, Jonl White (30 minutes) 89-004
13 Recess 3:00
14 Call to Order, 8:00pm
15 Other Subcommittee Reports
16 Recess 10:00
17 Call to Order, January 17, 9:00am Chart Room
18 Other Subcommittee Reports
19 Coffee Break 10:30am
20 Cleanup Subcommittee, Larry Masinter
21 Lunch 12:00 Voyage Room Restaurant
22 Cleanup continuation
23 Break 3:00
24 Cleanup continuation
25 Recess 4:30pm
26 Luau 6:45pm
27 Call to Order, January, 18 9:00am Paddle Room
28 Cleanup continuation
29 Coffee Break 10:30
30 Cleanup continuation
31 Lunch, 12:00 Voyage Room Restaurant
32 Cleanup continuation
33 Recess, 3:00pm
34 Call to Order, January, 18 7:00pm
35 Cleanup continuation
36 Adjournment
* Monday 8:00 - ISO discussion
Not part of X3J13 Committee Meeting
∂05-Jan-89 1616 lansky@ai.sri.com SRI AIRR Seminar: TUESDAY, JANUARY 10, 2pm -- John Josephson
Received: from Warbucks.AI.SRI.COM by SAIL.Stanford.EDU with TCP; 5 Jan 89 16:16:04 PST
Received: from venice.ai.sri.com by Warbucks.AI.SRI.COM with INTERNET ;
Thu, 5 Jan 89 15:58:33 PST
Received: by venice.ai.sri.com (3.2/4.16)
id AA01659 for planlunch@ai.sri.com; Thu, 5 Jan 89 15:58:39 PST
Date: Thu, 5 Jan 89 15:58:39 PST
From: lansky@Warbucks.AI.SRI.COM (Amy Lansky)
Message-Id: <8901052358.AA01659@venice.ai.sri.com>
To: planlunch@Warbucks.AI.SRI.COM
Subject: SRI AIRR Seminar: TUESDAY, JANUARY 10, 2pm -- John Josephson
VISITORS: Please arrive 5 minutes early so that you can be escorted up
from the E-building receptionist's desk. Thanks!
-----------------------------------------------------------------------
ABDUCTION, DEDUCTION, INDUCTION AND PREDICTION
John R. Josephson (Josephson@osu-20.ircc.ohio-state.edu)
Ohio State University Laboratory for AI Research (LAIR)
Department of Computer and Information Science
2:00 PM, TUESDAY, January 10
SRI International, Building E, Room EJ228
Abduction has been described as a distinctive form of inference,
separate from both deduction and induction. Other terms that have
been used for essentially the same inference pattern include:
inference to the best explanation, hypothetic inference, eliminative
induction, differential diagnosis, and the explanatory inference. It
is the ``hypothetico-'' in the ``hypothetico-deductive'' model of the
scientific method, and often the ``hypothesize'' in the ``hypothesize
and test'' weak method in AI. The objectives of this talk will be to
describe and characterize abductive inference, and to clarify some
relationships to deduction and induction. In particular I will argue
that some abductions are deductions, but some are not, and that
inductive generalizations can be insightfully analyzed as special
cases of abductions. I will argue that predictions are a distinctive
form of inference; they are not abductions and are sometimes
deductive, sometimes not. The result will be a new taxonomy of basic
inference types.
∂06-Jan-89 0843 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Urgent: Update to PODC Call for Papers
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Jan 89 08:43:18 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA27594; Fri, 6 Jan 89 08:41:47 PDT
Message-Id: <8901061641.AA27594@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Fri, 6 Jan 89 08:42:01 PST
Received: by BYUADMIN (Mailer R2.01A) id 0052; Fri, 06 Jan 89 09:39:51 MST
Date: Fri, 6 Jan 89 10:01:11 EST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
mischu@ALLEGRA.ATT.COM
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
From: mischu@ALLEGRA.ATT.COM
Subject: Urgent: Update to PODC Call for Papers
Comments: To: arpa!theorynt@vm1.nodak.edu
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Corrections to PODC Call for Papers.
Because of scheduling problems and printing errors, the original
PODC Call for Papers has several inaccuracies. The copy
below contains corrections to various earlier versions.
In particular:
Abstracts are due January 30. (No later postmarks-REALLY!)
Acceptance Notification is April 5.
My room number is 3D-458.
Please send 13 copies of the abstract (not 4).
Michael Merritt
______________________________________________________________________
CALL FOR PAPERS
Eighth ACM SIGACT-SIGOPS Symposium on
Principles of Distributed Computing
*************
* (PODC'89) *
*************
August 14-16, 1989
Edmonton, Alberta, Canada
Original research contributions are sought that address fundamental
issues in the theory and practice of distributed and concurrent
systems. Topics of interest include, but are not limited to:
- Principles of distributed computation derived from
practical experience with working systems
- Algorithms and complexity
- Specification, semantics, and verification
- Programming languages and programming language constructs
- Fault tolerance
- Cryptography and security
Important dates:
Jan. 30, 1989 Abstracts due
Apr. 5, 1989 Acceptance notification
May 15, 1989 Camera-ready version due
Please send 13 copies of a detailed abstract (not the complete paper),
with the address, e-mail address, and telephone number, to the Program
Chair:
Michael Merritt
AT&T Bell Laboratories
Room 3D-458
600 Mountain Avenue
Murray Hill, NJ 07974
U.S.A.
e-mail: allegra!mischu
The abstract must provide sufficient details to allow the program
committee to assess the merits of the paper and should include
appropriate references to and comparisons with literature. It is
recommended that each submission begin with a succinct statement of
the problem, a summary of the main results, and a brief explanation of
the significance and relevance to the conference, all suitable for a
non-specialist. Technical development of the work, directed to the
specialist, should follow. A limit of 10 typed double-spaced pages is
placed on submissions. If the authors believe that more details are
essential to substantiate the main claims of the paper, they are
encouraged to include a clearly marked appendix that will be read at
the discretion of the Program Committee.
Abstracts conforming to the guidelines will be considered by the
committee if they are postmarked by the deadline of January 30th,
1989, and are received within a reasonable time thereafter.
The Program Committee:
Yehuda Afek, AT&T and Tel Aviv University
Baruch Awerbuch, MIT
Edmund Clarke, Carnegie Mellon
Cynthia Dwork, IBM
Michael Fischer, Yale University
Mohamed Gouda, Univ. of Texas at Austin
Maurice Herlihy, Carnegie Mellon
Michael Merritt, AT&T
David Peleg, Weizmann Institute, Israel
Charles Rackoff, University of Toronto
Peter Weinberger, AT&T
Pierre Wolper, University of Liege, Belgium
Conference Chair:
Piotr Rudnicki, The University of Alberta, Edmonton, Canada,
(piotr@alberta.UUCP)
Publicity Chair:
M. Tamer Ozsu, The University of Alberta, Edmonton, Canada,
(ozsu@alberta.UUCP)
______________________________________________________________________
∂06-Jan-89 0917 aaai@sumex-aim.stanford.edu Council Conference Call
Received: from sumex-aim.stanford.edu by SAIL.Stanford.EDU with TCP; 6 Jan 89 09:17:13 PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA18180; Fri, 6 Jan 89 09:14:46 PST
Date: Fri, 6 Jan 1989 9:14:45 PST
From: AAAI <aaai@sumex-aim.stanford.edu>
To: officers:;@sumex-aim.stanford.edu
Cc: aaai@sumex-aim.stanford.edu
Subject: Council Conference Call
Message-Id: <CMM.0.88.600110085.aaai@sumex-aim.stanford.edu>
For members of the Council and AAAI Officers, we will be holding a
conference call next week on Thursday, January 12, at 4:30 pm (EST)
or 1:30 pm (PST). We plann to discuss the status of the membership,
NTU, etc.
If you plan to participate, please send me your phone number.
Claudia
∂06-Jan-89 0921 @Score.Stanford.EDU:tom@polya.Stanford.EDU Dover retirement
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Jan 89 09:21:29 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 6 Jan 89 09:18:07-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA28348; Fri, 6 Jan 89 09:18:11 PDT
Date: Fri, 6 Jan 89 09:18:11 PDT
From: Tom Dienstbier <tom@polya.Stanford.EDU>
Message-Id: <8901061718.AA28348@polya.Stanford.EDU>
To: faculty@score, csd@score
Subject: Dover retirement
Folks, we have come to an end of another era. The DOVER printer has been
de-comissioned. Officially on the 31st of December Dover has been shut off.
This will almost end the existence of the experimental 3MB ether net in
Margaret Jacks Hall. The system SAIL is the only host that is running on
the 3MB segment. The Dovers and associated equipment IFS, ALTOS, were part
of a grant from XEROX Corporation to the Computer Science Department in
1979/1980. The Dovers have been real "work horses" to the department printing
millions of pages of text and graphics. At one time, CSDCF was operating three
of these laser printers. The Altos were essentially the first limited
production workstation that utilized a mouse and mouse driven menus.
The IFS was equally important in that it was the first system to be used
as a dedicated file server.
This equipment will be surplused through Surplus Sales on campus
if anyone is interested in some of the hardware. I can supply additional
details about the equipment if needed.
Tom
∂06-Jan-89 1023 @Score.Stanford.EDU:chandler@polya.Stanford.EDU 1-10-89 Faculty Meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Jan 89 10:23:14 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 6 Jan 89 10:20:39-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA00579; Fri, 6 Jan 89 10:21:30 PDT
Date: Fri, 6 Jan 1989 10:21:13 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, bureaucrats@score
Subject: 1-10-89 Faculty Meeting
Message-Id: <CMM.0.87.600114073.chandler@polya.stanford.edu>
Here is the agenda for next Tuesday's Faculty Meeting to be held at 2:30 in
MJH-146.
Approval of degree candidates
--Sharon Hemenway
Brief discussion of recommended procedure for deciding about any changes to the PhD program
Staff Reports
1. Computer Forum
--Carolyn Tajnai
2. Computer Facilities
--Jim Ball
3. Financial
--George Wheaton
--Betty Scott
4. Education
--Roy Jones
5. Other
Faculty Actions
1. Recommendations to appoint Consulting Professors
--Doug Lenat
--Bill Clancey
2. Report on progress of searches
Theory
--Don Knuth
Programming Languages
--Daniel Weise
Robotics
--Jean-Claude Latombe
Asst. Chairman for Educational Affairs
--Roy Jones
Report on progress of new building
--George Wheaton
Other
∂06-Jan-89 1203 @Score.Stanford.EDU:winograd@loire.stanford.edu SEMINAR ON COMPUTERS, ETHICS, and SOCIAL RESPONSIBILITY
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Jan 89 12:03:20 PST
Received: from loire.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 6 Jan 89 12:00:41-PST
Received: by loire.stanford.edu (5.59/25-eef) id AA02035; Fri, 6 Jan 89 12:00:46 PDT
Date: Fri, 6 Jan 89 12:00:46 PDT
Message-Id: <8901062000.AA02035@loire.stanford.edu>
From: Winograd@csli.stanford.edu
To: ethdist@loire.stanford.edu
Subject: SEMINAR ON COMPUTERS, ETHICS, and SOCIAL RESPONSIBILITY
SEMINAR ON COMPUTERS, ETHICS, and SOCIAL RESPONSIBILITY
Winter Quarter 1988-89
Helen Nissenbaum and Terry Winograd
Mondays 1:15-3:15 -- FIRST MEETING JANUARY 9
Margaret Jacks Hall Room 460-252
During the coming quarter we will be holding a weekly seminar on the
teaching of ethics and social responsibility topics to computer science
students. The major focus will be on the preparation of an
undergraduate course which will be offered beginning this Spring by
Computer Science, Symbolic Systems and VTSS. The development of that
course is being sponsored by a special grant from the Dean of
Undergraduate Studies and by the CS Department and Symbolic Systems
Program. The seminar this quarter will serve both a workshop for
putting together the undergraduate course and as a forum for discussion
of the underlying issues.
In a recent VTSS forum, John McCarthy argued that when technologists
attempt to consider the social and ethical implications of their work,
the material they cover tends to be a matter of fashion, the discussion
ignorant, and the direction politically motivated. This pessimism is
shared by many of our colleagues and students. It may be difficult to
get beyond it, but it is not impossible. The challenge in both the
seminar and the subsequent course is to provide students with skills
and background that will prepare them to consider important and
enduring questions, with informed intelligence, and with a direction
that is political not in the narrow sense of limited ideologies, but in
the broad sense of being concerned with the good of society.
Part of the work will include reading and reporting on available
materials, designing reading sequences, projects and lessons, and
preparing bibliographies. Sessions will presentation by an outside
speaker, with discussion by the participants.
Students interested in participating for credit will be able to sign up
for CS399 (Independent Project). There are also some TA funds
available for students who will take on independent responsibility for
some of the work of organizing for the Spring course.
For more information contact Terry Winograd (winograd@csli.stanford.edu
-- 3-2780) or Helen Nissenbaum (helen@csli.stanford.edu -- 3-4091).
----- End Forwarded Message -----
∂06-Jan-89 1216 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Urgent: Semantics of Programming Languages
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Jan 89 12:16:43 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA05801; Fri, 6 Jan 89 12:14:43 PDT
Message-Id: <8901062014.AA05801@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Fri, 6 Jan 89 12:14:57 PST
Received: by BYUADMIN (Mailer R2.01A) id 7025; Fri, 06 Jan 89 13:12:57 MST
Date: Fri, 6 Jan 89 13:08:06 CST
Reply-To: revesz%yktvmh.BITNET@forsythe.stanford.edu
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
From: ND HECN E-mail Postmaster <INFO%NDSUVM1.BITNET@forsythe.stanford.edu>
Subject: Urgent: Semantics of Programming Languages
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
This was sent as a file to THEORYNT (?) and was bounced to me because
it came as a file and not a mail item. I am posting it for Dr. Revesz.
His mailing address is REVESZ@YKTVMH.Bitnet .
Marty Hoag - North Dakota HECN e-mail Postmaster
Subject: Urgent: Semantics of Programming Languages
The Programming Languages and Foundations Department
of the IBM T.J. Watson Research Center
Announces a series of distinguished lectures on the
SEMANTICS OF PROGRAMMING LANGUAGES
---------------------------------------------------------------------------
January 26 An ultimate "Kahn Principle" for dataflow semantics
Albert Meyer, MIT
---------------------------------------------------------------------------
February 23 How far do we need to automate proofs?
Dana Scott, Carnegie Mellon University
---------------------------------------------------------------------------
March 23 Title to be announced later
Samson Abramsky, Imperial College
---------------------------------------------------------------------------
April 27 Title to be announced later
John Mitchell, Stanford University
---------------------------------------------------------------------------
May 25 Type structure and categories
John Reynolds, Carnegie Mellon University
---------------------------------------------------------------------------
Time: 3 PM
Location: IBM T.J. Watson Research Center, Hawthorne, NY.
Visitors are welcome. Please make arrangements in advance by contacting
Dr. Gyorgy Revesz at (914) 789-7871.
IBM T.J. Watson Research Center
P.O. Box 704
Yorktown Heights, NY 10598
∂06-Jan-89 1239 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu URGENT: Noerteastern University Theory Day
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Jan 89 12:38:52 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA06928; Fri, 6 Jan 89 12:37:15 PDT
Message-Id: <8901062037.AA06928@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Fri, 6 Jan 89 12:37:30 PST
Received: by BYUADMIN (Mailer R2.01A) id 7427; Fri, 06 Jan 89 13:35:40 MST
Date: Fri, 6 Jan 89 15:11:55 EST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
andrew klapper <klapper%CORWIN.CCS.NORTHEASTERN.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
From: andrew klapper <klapper%CORWIN.CCS.NORTHEASTERN.EDU@Forsythe.Stanford.EDU>
Subject: URGENT: Noerteastern University Theory Day
Comments: To: THEORYNT@vm1.nodak.edu
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
-------------------------------------------------------------------------------
The College of Computer Science at Northeastern University
announces its 1989
THEORY DAY
Friday, January 27, 1989
........................... Schedule of Events ................................
10:00 AM Eric Allender "Limitations of the Upward Separation Technique"
11:00 AM Joan Feigenbaum "Generating Hard Certified Elements of
NP-Complete Sets"
12:00 PM Lunch Break
2:00 PM Gilles Brasard "Minimum Disclosure Proofs of Knowledge"
3:30 PM Ken Macalloon "Constraint Logic Programming"
All talks will take place in room 356 Ell Center on the Northeastern University
campus. Parking on campus will be available but requires prior approval. For
information about visitor parking and maps of campus or for any other
information, please contact Gayle Mackay:
College of Computer Science
Northeastern University
360 Huntington Ave.
Boston, MA 02115
(617) 437-2464
or contact Andy Klapper at klapper@corwin.ccs.northeastern.edu
∂06-Jan-89 1304 ULLMAN@Score.Stanford.EDU help save some fish
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Jan 89 13:04:44 PST
Date: Fri 6 Jan 89 13:00:53-PST
From: Jeffrey D. Ullman <ULLMAN@Score.Stanford.EDU>
Subject: help save some fish
To: faculty@Score.Stanford.EDU, staff@Score.Stanford.EDU,
phd@Score.Stanford.EDU
Message-ID: <12460458144.26.ULLMAN@Score.Stanford.EDU>
I have 4 tropical fish that need a home while I am on sabbatical.
Ideally, I'd like to close down the tank permanently.
Can you take these fish (2 kissing gouramis, 2 neon tetras)
and give them a home in your tank?
---jdu
-------
∂06-Jan-89 1442 ARCEO@Warbucks.AI.SRI.COM SEMINAR - JANUARY 11th (Wednesday)
Received: from Warbucks.AI.SRI.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89 14:42:46 PST
Date: Fri 6 Jan 89 14:22:47-PST
From: ARCEO@Warbucks.AI.SRI.COM (Dori Arceo)
Subject: SEMINAR - JANUARY 11th (Wednesday)
To: AIC-Staff@Warbucks.AI.SRI.COM, planlunch@Warbucks.AI.SRI.COM,
CSL-Staff@CSL.SRI.COM, BBoard@KL.SRI.COM
cc: Waldinger@Warbucks.AI.SRI.COM
Message-ID: <600128567.0.ARCEO@WARBUCKS.AI.SRI.COM>
Mail-System-Version: <VAX-MM(229)+TOPSLIB(126)@WARBUCKS.AI.SRI.COM>
TITLE: Refinement of Data
SPEAKER: Prof. Ralph Back
Department of Computer Science
Abo Akademi
Turku, Finland
TIME: 4:15 Wednesday, January 11
PLACE: AI Center Conference Room
EJ 228
Building E, SRI International
ABSTRACT:
The refinement calculus gives a formal basis for the stepwise-refinement
method of program construction. It is an extension of the weakest-precondition
calculus of Dijkstra, and is based on a relation of refinement between program
statements. This relation is a partial order when the semantics of statements
is identified with their predicate transformers. The talk describes how to
handle data refinement within this calculus, i.e., how to change the data
representation within a program in a systematic manner by a sequence of
correctness-preserving program transformations. The method proposed can also
handle nondeterministic abstraction functions (cases where a concrete program
state may represent many different abstract states). This is achieved by
introducing statements with an angelic (don't know) nondeterminism, in
addition to the usual demonic (don't care) nondeterminism assumed by Dijkstra.
The resulting specification/programming language is given a game-theoretic
weakest-precondition semantics. The method permits different representations
of a data abstraction to coexist in a program statement, using explicit
representation and abstraction statements to move from one representation to
another.
-------
∂06-Jan-89 1504 X3J13-mailer Ballots, please
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89 15:04:38 PST
Received: from Semillon.ms by ArpaGateway.ms ; 06 JAN 89 00:23:39 PST
Date: 6 Jan 89 00:23 PST
From: masinter.pa@Xerox.COM
Subject: Ballots, please
To: X3J13@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
Message-ID: <890106-002339-193@Xerox>
We've gotten very few ballots back. Please let us know soon if you plan to
vote even if you can't get your ballot in right away; we'll need some time
to respond to some of the comments and prepare new versions for the
meeting!
Thanks,
Larry
∂06-Jan-89 2136 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Urgent: SPAA Deadline Approaching. Call for papers follows:
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Jan 89 21:36:26 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA21822; Fri, 6 Jan 89 19:50:44 PDT
Message-Id: <8901070350.AA21822@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Fri, 6 Jan 89 19:51:00 PST
Received: by BYUADMIN (Mailer R2.01A) id 0412; Fri, 06 Jan 89 20:48:35 MST
Date: Fri, 6 Jan 89 22:41:04 EST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
ftl%MATH.MIT.EDU@Forsythe.Stanford.EDU
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
From: ftl%MATH.MIT.EDU@Forsythe.Stanford.EDU
Subject: Urgent: SPAA Deadline Approaching. Call for papers follows:
Comments: To: theorynt@vm1.nodak.edu
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
CALL FOR PAPERS
1989 ACM Symposium on
Parallel Algorithms and Architectures
The 1st Annual ACM Symposium on Parallel Algorithms and
Architectures will be held in Santa Fe, New Mexico on June 18--21,
1989. The Symposium is sponsored by the ACM SIGACT and SIGARCH in
cooperation with the IEEE and EATCS.
Papers presenting original research on fundamental advances in
parallel algorithms and architectures are sought. Suggested topics
for papers include:
parallel algorithms
parallel architectures
parallel complexity theory
communication networks
machine models
programming paradigms and general problem solving techniques
VLSI computation
resource tradeoffs
VLSI design
wafer-scale integration
fault tolerance
testing
Persons wishing to submit a paper should send 15 copies of an extended
abstract by January 20, 1989 to
Larry Snyder
Dept. of Computer Science FR-35
University of Washington
Seattle WA 98195
To be considered, papers must either be airmail postmarked by January
20, 1989 or be received by January 24, 1989. Authors will be notified
of acceptance or rejection by March 6, 1989. A final copy of each
accepted paper, prepared according to ACM guidelines for inclusion in
the Symposium proceedings, will be due by April 10, 1989.
Submission format: Abstracts should begin with a succinct statement of
the problems that are addressed in the paper, the main results
achieved, an explanation of the significance of the work, and a
comparison of the work to past research in the field. This material
should be readily understandable to nonspecialists. Technical
development, directed toward the specialist, should follow as
appropriate. The entire extended abstract should not exceed 4000
words or 10 double-spaced pages.
Symposium format: Authors of accepted papers will be expected to
present their work at the Symposium. The selection of papers and the
format of the meeting will be determined by the Program Committee.
Greatest consideration will be given to papers that present novel
research and demonstrable advances of either a theoretical or
practical nature in parallel algorithms and architectures.
Outstanding Paper Award: This award will be given for that paper which
the Program Committee judges to be particularly outstanding. At its
discretion, the Committee may decline to make the award or may split
the award among two or more papers.
Conference Chair:
Tom Leighton
Math Department and
Lab for Computer Science
MIT
Cambridge, MASS 02139
Program Committee Chair:
Larry Snyder
Dept. of Computer Science FR-35
University of Washington
Seattle, WA 98195
Local Arrangements Chair:
Ernest Brickell
Theoretical Computer Science Division, 1423
Sandia National Labs
Albuquerque, NM 87185
Program Committee:
Alok Aggarwal
Faith Fich
H.T. Kung
Charles Leiserson
Thomas Lengauer
Gary Miller
Sartaj Sahni
Chuck Seitz
Burton Smith
Larry Snyder
Quentin Stout
Jeff Ullman
∂06-Jan-89 2239 @Score.Stanford.EDU:cheriton@Pescadero.Stanford.EDU Re: Dover retirement
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Jan 89 22:39:06 PST
Received: from Pescadero.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 6 Jan 89 22:36:03-PST
Received: by Pescadero.Stanford.EDU (5.59/25-eef) id AA09327; Fri, 6 Jan 89 22:39:01 PDT
Date: Fri, 6 Jan 89 22:39:01 PDT
From: David Cheriton <cheriton@Pescadero.Stanford.EDU>
Message-Id: <8901070639.AA09327@Pescadero.Stanford.EDU>
To: csd@score, faculty@score, tom@polya.Stanford.EDU
Subject: Re: Dover retirement
In-Reply-To: <8901061718.AA28348@polya.Stanford.EDU> from Tom Dienstbier
<tom@polya.Stanford.EDU> on Fri, 6 Jan 89 09:18:11 PDT
I am very pleased that Tom took the effort to briefly document some of the
history, i.e. give an epitath for the Dover/Altos. The Xerox grant predates
me by several years so I dont know the full story.
It would be wonderful if "someone" from that era could write a note to Xerox
as a brief final report on that grant. I think it had a big impact!
As I sit placing orders for 10 MIP workstations with 16 megabytes or more
of memory, I realize how much the world has changed from those days.
∂06-Jan-89 2253 X3J13-mailer Issue: DECLARE-TYPE-FREE (Version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89 22:52:59 PST
Received: from Semillon.ms by ArpaGateway.ms ; 06 JAN 89 22:51:48 PST
Date: 6 Jan 89 22:51 PST
From: masinter.pa@Xerox.COM
To: X3J13@Sail.Stanford.Edu
Subject: Issue: DECLARE-TYPE-FREE (Version 9)
reply-to: cl-cleanup@sail.stanford.edu
line-fold: NO
Message-ID: <890106-225148-2007@Xerox>
This issue will be voted separately at the X3J13 meeting.
I (unfortunately) caused some controversy by changing the
sense of the proposal at the last minute. I'm sorry, as I do
not feel stringly about this issue, although there are some
additional considerations. I've included some, but not all,
Additional Comments at the end.
This version has two proposals, both the ALLOW proposal
which I introduced with version 8 and a LEXICAL proposal.
The difference is about whether a type declaration affects only variable
references within its scope, or also affects variable references that
are outside the scope of the declaration but dynamically inside the
execution of a form that is itself inside the scope of the declaration.
This really has nothing to do with the original goal of the proposal,
since exactly the same issue arises for a type declaration attached
to a binding of a special variable.
If you've yet to complete your ballot, please indicate which
version of the proposal you're votes apply to.
!
Forum: Cleanup
Issue: DECLARE-TYPE-FREE
References: CLtL p.158
DECLARATION-SCOPE
Related issues: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
DECLARATION-SCOPE
Category: CLARIFICATION/ADDITION
Edit history: Version 1, 18-Sep-88, Moon
Version 2, 22-Sep-88, Moon
(small edits to reflect mail discussion)
Version 3, 22-Sep-88, Masinter
Version 4, 27-Sep-88, JonL
Version 5, 30-Sep-88, Masinter (cost to implementors)
Version 6, 06-Oct-88, Pitman (minor edits in Discussion)
Version 7, 5-Dec-88, Masinter (scope->extent)
Version 8, 7-Dec-88, Masinter (back to scope)
Version 9, 2-Jan-89, Moon (2 proposals, to clarify discussion)
Problem description:
Section 9.2 of CLtL, p158, says that a declaration specifier like
(TYPE type var1 var2 ...) "... affects only variable bindings".
Since declarations can occur in contexts other than establishing
"variable bindings", most people interpret this statement to mean
that type declarations not in such context are either (1) completely
to be ignored, or (2) invalid CL syntax. Thus both of the following
forms would be suspect in that the type declarations could not have
any effect:
(if (and (typep x 'fixnum) (typep y 'fixnum))
(locally (declare (fixnum x y)) ;LOCALLY does not bind
...algorithm using x and y...) ; any variables.
...similar algorithm using x and y...)
(let ((y 'foo))
(setq y 10)
(let ((x 5)) ;'y' is not being bound in
(declare (fixnum y)) ; this particular context.
(incf y)
...random algorithm...))
Proposal (DECLARE-TYPE-FREE:ALLOW):
Specify that a type declaration does not only "affect variable bindings";
rather, type declarations are legal in all declarations. The interpretation
of a type declaration is that, during the execution of any expression
within the scope of the declaration, it is an error for the value of
the declared variable not to be of the declared type. For declarations
that are associated with variable bindings, the type declaration also
applies to the initial binding of the variable. In the special case
of a declaration for which there are no executable expressions
within the scope of the declaration (e.g., (locally (declare (integer x)))),
the result is as if there were executable expressions.
In this proposal, a type declaration affects not only variable
references within its scope, but also affects variable references that
are outside the scope of the declaration but dynamically inside the
execution of a form that is itself inside the scope of the
declaration. Such references can exist when the variable is SPECIAL
or when the declaration is not attached to the variable's binding, so
that the scope of the declaration does not include the entire scope
of the variable.
Proposal (DECLARE-TYPE-FREE:LEXICAL):
Specify that a type declaration does not only "affect variable bindings";
rather, type declarations are legal in all declarations. The interpretation
of a type declaration is that, during the execution of any reference to the
declared variable within the scope of the declaration, it is an error for
the value of the declared variable not to be of the declared type; and
during the execution of any SETQ of the declared variable within the scope
of the declaration, it is an error for the newly assigned value of the
declared variable not to be of the declared type; and at the moment the
scope of the declaration is entered, it is an error for the value of the
declared variable not to be of the declared type.
In this proposal, a type declaration affects only variable references within
its scope, and the meaning of "free" and "variable-binding-associated" type
declarations can be described identically.
This proposal is equivalent to saying that the meaning of a type declaration
is equivalent to changing each reference to <var> within the scope of the
declaration to (THE <type> <var>), changing each expression assigned to the
variable within the scope of the declaration to (THE <type> <new-value>),
and executing (THE <type> <var>) at the moment the scope of the declaration
is entered.
Examples:
;; this is an error under DECLARE-TYPE-FREE:ALLOW:
;; the assertion that x is a fixnum is violated between the two
;; calls to (zap)
;; this is a valid program under DECLARE-TYPE-FREE:LEXICAL
(let ((x 12) (y 'foo))
(flet ((zap () (rotatef x y)))
(locally (declare (fixnum x))
(zap)
(zap)
x)))
;; this is an error under both proposals
(let ((x 12) (y 'foo))
(flet ((zap () (rotatef x y)))
(locally (declare (fixnum x))
(zap)
(print x)
(zap)
x)))
;; this is an error under DECLARE-TYPE-FREE:ALLOW, because
;; the assertion that x is a fixnum
;; is violated during the call to zap, even though few
;; implementations will be able to check:
;; this is a valid program under DECLARE-TYPE-FREE:LEXICAL
(let ((x 12) (y 'foo))
(flet ((zap ()
(rotatef x y)
(rotatef x y)))
(locally (declare (fixnum x))
(zap)
x)))
;; this is an error under both proposals, even though the
;; violation of the type constraint happens after the form
;; with the declaration is exited.
(let ((f (let ((x 3))
(declare (fixnum x))
#'(lambda (z) (incf x z)))))
(funcall f 4.3))
Rationale:
This proposal enables optimizing compilers to make use of the otherwise
ignored type information. Many people have often asked for it, and
there is no strong reason to forbid it.
DECLARE-TYPE-FREE:ALLOW is more restrictive on programs and hence allows
more freedom for optimizing compilers. DECLARE-TYPE-FREE:LEXICAL is easier
to understand but allows a specialized representation only where the scope
of the variable is the same as the scope of the declaration or the compiler
can prove that there are no relevant other references to the variable.
Current practice:
Lucid Common Lisp allows "free" type declarations; under some
circumstances the compiler issues a warning message that such usage
is an extension to Common Lisp.
Cost to Implementors:
Implementations that might currently warn about such declarations
would have to remove the warning; otherwise, it is valid to ignore
type declarations.
Cost to Users:
None, this is a compatible addition.
Cost of non-adoption:
Common Lisp will be less self-consistent.
Benefits:
Programmers will be able to use type declaration to express their
intent, rather than having to manually insert THE wrappers around
every reference.
Esthetics:
It is a simpler interpretation for type declaration specifiers, with
fewer special cases; hence reduces the number of exceptions in the
language.
Discussion:
Another cleanup issue, DECLARATION-SCOPE, addresses the scope of
declarations. This proposal carefully uses the phrase "within the
scope of the declaration" to avoid confounding the two issues.
This issue has been discussed at the Fort Collins X3J13 meeting in
November 1987, and at length on the various electronic mailing lists.
At least one current implementation is able to generate more efficient
code when declarations are associated with a particular binding, since
it then has the option to choose type-specific specialized storage for
the runtime value of the variable. So, for example,
(let ((x v)) (declare (type float x)) (+ x x))
is sometimes more efficient than
(let ((x v)) (locally (declare (type float x)) (+ x x)))
However, the local type declarations allowed by this proposal do
provide some useful information, even if it is not the *most* useful.
It is possible for a sufficiently "smart" compiler to infer the
equivalent of a "binding declaration" when it can ascertain that the
type of the binding value -- 'v' above -- is commensurate with the
type locally declared over the scope of usage of the variable.
It may be useful for a compiler to issue a warning whenever it finds
nested type declarations referring to the same variable and the
intersection of the declared types is null.
Documentation might want to discuss the style implications of
nested declarations intersecting. The interesting cases are:
- An inner declaration could be a subtype of an outer one.
This is the most useful case and probably the only one to
be encouraged in code written by humans. e.g.,
(locally (declare (type number x))
(locally (declare (type integer x))
...use X as integer...))
- An outer declaration could be a subtype of an inner one.
This is useless but harmless. It might happen as the result
of certain macro situations. e.g.,
(locally (declare (type integer x))
(locally (declare (type number x))
...use X as integer...))
- Two types may only partially overlap. This would presumably
happen only as the result of a macro expansion.
(locally (declare (type fixnum x))
(locally (declare (type (or bit package) x))
...use X as BIT...))
!
Additional Comments:
"The ALLOW proposal has the problems that:
- It isn't enforceable.
- In exactly those cases where it is enforceable, it's useful to enforce.
In those case where it is not enforceable (the odd middle-ground cases
in the Examples), it doesn't help you any to enforce the restriction, and
it might get in your way.
"
"Btw, both versions 8 and 9 have the non-preemptive problem that the
only examples they provide illustrate what happens in the screw
cases. This might lead some people to think that this whole issue
is kind of random. I think there should be a few examples of the
"normal use" (such as the un-filled-out examples in the problem
description). "
"Suppose I have
(defun frob (delta)
(flet ((more (x) (+ x delta)))
;; if you like, put (declare (inline more)) here
(typecase delta
(float (locally (declare (type float delta))
... (more rho ) ... )
((signed-byte 8)
(locally (declare (type (signed-byte 8) delta))
... (more zz) ... )
...)
Even without the INLINE, it is a common & legal transformation
to do inline substitution on small FLETted functions. Even though
the reference DELTA in the definition of MORE isn't within the
lexical scope of the local declaration, it *is* the same delta. While
its not impossible to maintain a separate contour in order to segregate
the type declarations, it seems like unnecessary work, and in fact, the
declaration is quite useful if MORE is inlined. This is only the case
with the ALLOW proposal and not the LEXICAL proposal."
∂07-Jan-89 0933 X3J13-mailer Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS, version 8
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Jan 89 09:33:34 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA19606; Sat, 7 Jan 89 10:32:25 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA08861; Sat, 7 Jan 89 10:32:22 MST
Date: Sat, 7 Jan 89 10:32:22 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901071732.AA08861@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS, version 8
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
References: CLtL pages 66-70, 143
Category: CLARIFICATION
Edit history: V1, 07 Oct 1987 Sandra Loosemore
V2, 15 Oct 1987 Sandra Loosemore
V3, 15 Jan 1988 Sandra Loosemore
V4, 06 May 1988 Sandra Loosemore
V5, 20 May 1988 Sandra Loosemore
V6, 09 Jun 1988 Sandra Loosemore
V7, 16 Dec 1988 Sandra Loosemore
(Comments from Pitman, change DEFCONSTANT, etc.)
V8, 31 Dec 1988 Sandra Loosemore
(CLOS additions, etc.)
Problem Description:
Standard programming practices assume that, when calls to defining
macros such as DEFMACRO and DEFVAR are processed by COMPILE-FILE,
certain side-effects occur that affect how subsequent forms in the
file are compiled. However, these side-effects are not mentioned in
CLtL, except for a passing mention that macro definitions must be
``seen'' by the compiler before it can compile calls to those macros
correctly. In order to write portable programs, users must know
exactly which defining macros have compile-time side-effects and what
those side-effects are.
Inter-file compilation dependencies are distinct from, and not
addressed by, this issue.
Proposal: COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY
(1) Clarify that defining macros such as DEFMACRO or DEFVAR, appearing
within a file being processed by COMPILE-FILE, normally have
compile-time side effects which affect how subsequent forms in the
same file are compiled. A convenient model for explaining how these
side effects happen is that the defining macro expands into one or
more EVAL-WHEN forms, and that the calls which cause the compile-time
side effects to happen appear in the body of an (EVAL-WHEN (COMPILE)
...) form.
(2) The affected defining macros and their specific side effects are
as follows. In each case, it is identified what users must do to
ensure that their programs are conforming, and what compilers must do
in order to correctly process a conforming program.
DEFTYPE: Users must ensure that the body of a DEFTYPE form is
evaluable at compile time if the type is referenced in subsequent type
declarations. The compiler must ensure that the DEFTYPE'd type
specifier is recognized in subsequent type declarations. If the
expansion of a type specifier is not defined fully at compile time
(perhaps because it expands into an unknown type specifier or a
SATISFIES of a named function that isn't defined in the compile-time
environment), an implementation may ignore any references to this type
in declarations and/or signal a warning.
DEFMACRO, DEFINE-MODIFY-MACRO: The compiler must store macro
definitions at compile time, so that occurrences of the macro later on
in the file can be expanded correctly. Users must ensure that the
body of the macro is evaluable at compile time if it is referenced
within the file being compiled.
DEFUN: DEFUN is not required to perform any compile-time side effects.
In particular, DEFUN does not make the function definition available
at compile time. An implementation may choose to store information
about the function for the purposes of compile-time error-checking
(such as checking the number of arguments on calls), or to enable the
function to be expanded inline.
DEFVAR, DEFPARAMETER: The compiler must recognize that the variables
named by these forms have been proclaimed special. However, it must
not evaluate the initial value form or SETQ the variable at compile
time.
DEFCONSTANT: The compiler must recognize that the symbol names a
constant. An implementation may choose to evaluate the value-form at
compile time, load time, or both. Therefore users must ensure that
the value-form is evaluable at compile time (regardless of whether or
not references to the constant appear in the file) and that it always
evaluates to the same value.
DEFSETF, DEFINE-SETF-METHOD: The compiler must make SETF methods
available so that it may be used to expand calls to SETF later on in
the file. Users must ensure that the body of DEFINE-SETF-METHOD and
the complex form of DEFSETF are evaluable at compile time if the
corresponding place is referred to in a subsequent SETF in the same
file. The compiler must make these SETF methods available to
compile-time calls to GET-SETF-METHOD when its environment argument is
a value received as the &ENVIRONMENT parameter of a macro.
DEFSTRUCT: The compiler must make the structure type name recognized
as a valid type name in subsequent declarations (as for DEFTYPE) and
make the structure slot accessors known to SETF. In addition, the
compiler must save enough information about the structure type so that
further DEFSTRUCT definitions can :INCLUDE a structure type defined
earlier in the file being compiled. The functions which DEFSTRUCT
generates are not defined in the compile time environment, although
the compiler may save enough information about the functions to code
subsequent calls inline. The #S reader syntax may or may not be
available at compile time.
DEFINE-CONDITION: The rules are essentially the same as those for
DEFSTRUCT; the compiler must make the condition type recognizable as a
valid type name, and it must be possible to reference the condition
type as the parent-type of another condition type in a subsequent
DEFINE-CONDITION in the file being compiled.
DEFCLASS: The compiler must make the class name be recognized as a
valid type name in subsequent declarations (as for DEFTYPE) and be
recognized as a valid class name for DEFMETHOD parameter
specializers and for use as the :METACLASS option of a subsequent
DEFCLASS. The compiler must make the class definition available to
be returned by FIND-CLASS when its environment argument is a value
received as the &ENVIRONMENT parameter of a macro.
DEFGENERIC and DEFMETHOD: These are not required to perform any
compile-time side effects. In particular, the methods are not
installed for invocation during compilation. An implementation may
choose to store information about the generic function for the
purposes of compile-time error-checking (such as checking the number
of arguments on calls, or noting that a definition for the function
name has been seen).
DEFINE-METHOD-COMBINATION: The compiler is not required to perform
any compile-time side-effects.
DEFPACKAGE: All of the actions normally performed by this macro at load
time must also be performed at compile time.
(3) The compile-time side effects may cause information about the
definition to be stored differently than if the defining macro had
been processed in the "normal" way (either interpretively or by loading
the compiled file).
In particular, the information stored by the defining macros at
compile time may or may not be available to the interpreter (either
during or after compilation), or during subsequent calls to COMPILE or
COMPILE-FILE. For example, the following code is nonportable because
it assumes that the compiler stores the macro definition of FOO where
it is available to the interpreter:
(defmacro foo (x) `(car ,x))
(eval-when (eval compile load)
(print (foo '(a b c))))
A portable way to do the same thing would be to include the macro
definition inside the EVAL-WHEN:
(eval-when (eval compile load)
(defmacro foo (x) `(car ,x))
(print (foo '(a b c))))
Rationale:
The proposal generally reflects standard programming practices. The
primary purpose of the proposal is to make an explicit statement that
CL supports the behavior that most programmers expect and many
implementations already provide.
The primary point of controversy on this issue has been the treatment
of the initial value form by DEFCONSTANT, where there is considerable
variance between implementations. The effect of the current wording is
to legitimize all of the variants.
Current Practice:
Many (probably most) Common Lisp implementations, including VaxLisp
and Lucid Lisp, are already largely in conformance.
In VaxLisp, macro definitions that occur as a side effect of compiling
a DEFMACRO form are available to the compiler (even on subsequent
calls to COMPILE or COMPILE-FILE), but are not available to the
interpreter (even within the file being compiled).
By default, Kyoto Common Lisp evaluates *all* top level forms as they
are compiled, which is clearly in violation of the behavior specified
on p 69-70 of CLtL. There is a flag to disable the compile-time
evaluation, but then macros such as DEFMACRO, DEFVAR, etc. do not make
their definitions available at compile-time either.
Cost to implementors:
The intent of the proposal is specifically not to require the compiler
to have special knowledge about each of these macros. In
implementations whose compilers do not treat these macros as special
forms, it should be fairly straightforward to use EVAL-WHENs in their
expansions to obtain the desired compile-time side effects.
Cost to users:
Since CLtL does not specify whether and what compile-time side-effects
happen, any user code which relies on them is, strictly speaking,
nonportable. In practice, however, most programmers already expect
most of the behavior described in this proposal and will not find it
to be an incompatible change.
Benefits:
Adoption of the proposal will provide more definite guidelines on how
to write programs that will compile correctly under all CL
implementations.
Discussion:
Reaction to a preliminary version of this proposal on the common-lisp
mailing list was overwhelmingly positive. More than one person
responded with comments to the effect of "but doesn't CLtL already
*say* that somewhere?!?" Others have since expressed a more lukewarm
approval.
It has been suggested that this proposal should also include PROCLAIM.
However, since PROCLAIM is not a macro, its compile-time side effects
cannot be handled using the EVAL-WHEN mechanism. A separate proposal
seems more appropriate.
Item (3) allows for significant deviations between implementations.
While there is some sentiment to the effect that the compiler should
store definitions in a manner identical to that of the interpreter,
other people believe strongly that compiler side-effects should be
completely invisible to the interpreter. The author is of the opinion
that since this is a controversial issue, further attempts to restrict
this behavior should be considered as separate proposals.
It should be noted that user-written code-analysis programs must
generally treat these defining macros as special forms and perform
similar "compile-time" actions in order to correctly process
conforming programs.
∂07-Jan-89 0935 X3J13-mailer Issue CONSTANT-MODIFICATION, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Jan 89 09:35:06 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA19620; Sat, 7 Jan 89 10:33:59 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA08864; Sat, 7 Jan 89 10:33:56 MST
Date: Sat, 7 Jan 89 10:33:56 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901071733.AA08864@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: Issue CONSTANT-MODIFICATION, version 2
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: CONSTANT-MODIFICATION
References: CLtL p. 78, 87
Issue CONSTANT-COLLAPSING
Category: CLARIFICATION
Edit History: V1, 07 Nov 1988, Sandra Loosemore
V2, 12 Dec 1988, Sandra Loosemore
Problem Description:
CLtL states that an implementation is permitted to "collapse"
constants appearing in code to be compiled if they are EQUAL. This
implicit sharing of compiled data structures may result in
unpredictable behavior if destructive operations are performed.
However, CLtL does not explicitly allow or disallow destructive
operations on constants.
Proposal CONSTANT-MODIFICATION:DISALLOW:
Clarify that it is an error to destructively modify objects which are
self-evaluating forms or which appear inside of a QUOTE special form.
Rationale:
Disallowing modification of constants consistently in all situations,
rather than just in compiled code, is proposed because in some
compiled-only situations it may be difficult to distinguish between
"compiled" and "interpreted" code.
Current Practice:
Many implementations "collapse" compiled constants.
Many implementations treat compiled constants as read-only. In
PSL/PCLS, for example, quoted data structures in compiled code are
copied into a part of memory that is not scanned by the garbage
collector. The TI Explorer's loader also copies constants into a
write-protected memory area.
Cost to implementors:
None.
Cost to users:
User programs which perform destructive operations on constants are
already nonportable.
Benefits:
Many novice programmers do not realize that modifying quoted data
structures is an error in many implementations. Including an explicit
statement in the standard that doing so is a bad idea will reduce
confusion.
Discussion:
The issue of whether implementations are permitted to copy constants
seen by EVAL or COMPILE is discussed separately as issue QUOTE-MAY-COPY.
∂07-Jan-89 0944 X3J13-mailer **DRAFT** Issue COMPILER-DIAGNOSTICS, version 8
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Jan 89 09:44:40 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA19722; Sat, 7 Jan 89 10:43:32 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA08867; Sat, 7 Jan 89 10:43:26 MST
Date: Sat, 7 Jan 89 10:43:26 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901071743.AA08867@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: **DRAFT** Issue COMPILER-DIAGNOSTICS, version 8
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: COMPILER-DIAGNOSTICS
References: CLtL p. 438-439, 62, 69, 160, 161
Condition System, Revision #18
S:>KMP>cl-conditions.text.34
Issue GC-MESSAGES
Issue RETURN-VALUES-UNSPECIFIED
Issue COMPILER-VERBOSITY
Category: CLARIFICATION, ENHANCEMENT
Edit History: V1, 15 Oct 1988, Sandra Loosemore
V2, 19 Oct 1988, Sandra Loosemore (minor fixes)
V3, 25 Oct 1988, Sandra Loosemore (input from Pitman & Gray)
V4, 01 Nov 1988, Sandra Loosemore (fix typos)
V5, 15 Dec 1988, Dan L. Pierson (new condition types)
V6, 15 Dec 1988, Sandra Loosemore (additions, fix wording)
V7, 16 Dec 1988, Dan L. Pierson (minor cleanup)
V8, 07 Jan 1989, Sandra Loosemore (expand discussion)
Status: **DRAFT**
Problem Description:
It is unclear whether various diagnostics issued by the compiler are
supposed to be true errors and warnings, or merely messages.
In some implementations, COMPILE-FILE handles even serious error
situations (such as syntax errors) by printing a message and then
trying to recover and continue compiling the rest of the file, rather
than by signalling an error. While this user interface style is just
as acceptable as invoking the debugger, it means that a normal return
from COMPILE-FILE does not necessarily imply that the file was
successfully compiled.
Many compilers issue warnings about programming style issues (such as
binding a variable that is never used but not declared IGNORE).
Sometimes these messages obscure warnings about more serious problems,
and there should be some way to differentiate between the two. For
example, it should be possible to suppress the style warnings.
Also, neither CLtL nor issue RETURN-VALUES-UNSPECIFIED states what the
return value from COMPILE-FILE should be.
Proposal COMPILER-DIAGNOSTICS:USE-HANDLER:
(1) Add the following to the language:
NOTICE [Type]
The notice type is a subtype of CONDITION, disjoint from
WARNING, SEVERE-CONDITION, and SIMPLE-CONDITION. All types of
notices should inherit from this type.
SIMPLE-NOTICE [Type]
Conditions signalled by NOTICE when given a format string as a
first argument are of this type. This is a subtype of NOTICE,
and in implementations supporting multiple inheritance, this
type will also be a subtype of SIMPLE-CONDITION. The init
keywords :FORMAT-STRING and :FORMAT-ARGUMENTS are supported to
initialize the slots, which can be accessed using
SIMPLE-CONDITION-FORMAT-STRING and SIMPLE-CONDITION-FORMAT-ARGUMENTS.
ALERT [Type]
This is a subtype of NOTICE.
NOTICE datum &rest arguments [Function]
This function signals a condition of type NOTICE. The arguments
are interpreted similarly to those for the function WARN; if the
"datum" is a string, then a condition of type SIMPLE-NOTICE will
be signalled.
While the NOTICE is being signalled, this function establishes
the MUFFLE-NOTICE restart for use by a handler to cause the NOTICE
function to return immediately without further action. If no
handlers for the notice condition are found, or if all such
handlers decline, then the condition will be reported to
*ERROR-OUTPUT*.
The value returned by NOTICE is NIL.
MUFFLE-NOTICE [Function]
This function transfers control to the restart named MUFFLE-NOTICE.
If no such restart exists, MUFFLE-NOTICE signals an error of type
CONTROL-ERROR.
(2) Clarify that ERROR, WARNING, and ALERT conditions may be signalled
within COMPILE or COMPILE-FILE, including arbitrary errors which may
occur due to compile-time processing of (EVAL-WHEN (COMPILE) ...)
forms or macro expansion.
Considering only those conditions signalled -by- the compiler (as
opposed to -within- the compiler),
(a) Conditions of type ERROR may be signalled by the compiler in
situations where the compilation cannot proceed without
intervention.
Examples:
file open errors
syntax errors
(b) Conditions of type WARNING may be signalled by the compiler in
situations where the standard explicitly states that a warning must,
should, or may be signalled; and where the compiler can determine
that a situation that "is an error" would result at runtime.
Examples:
violation of type declarations
SETQ'ing or rebinding a constant defined with DEFCONSTANT
calls to built-in Lisp functions with wrong number of arguments
or malformed keyword argument lists
referencing a variable declared IGNORE
unrecognized declaration specifiers
(c) All other diagnostics issued by the compiler should be conditions
of type ALERT. In particular, this category includes all
diagnostics about matters of programming style. Although
conditions of type ALERT -may- be signalled in these
situations, no implementation is -required- to do so.
However, if an implementation does choose to signal a
condition, that condition will be of type ALERT and will be
signalled by a call to the function NOTICE.
Examples:
redefinition of function with different argument list
unreferenced local variables not declared IGNORE
declaration specifiers described in CLtL but ignored by
the compiler
(3) Require COMPILE-FILE to establish a condition handler. Add a
:HANDLER keyword argument to COMPILE-FILE, which is a user condition
handler function which is to be used during compilation. If the user
handler is not supplied or declines to handle a condition, then the
compiler's default handler will be invoked. Require the compiler
to handle the ABORT restart by aborting the smallest feasible part
of the compilation.
(4) Specify that COMPILE-FILE returns three values. The first value is the
truename of the output file, or NIL if the file could not be created.
The second value is non-NIL if errors were signalled during compilation
that were not handled by the user condition handler (indicating that
the output file is almost certainly unusable). The third value is
non-NIL if warnings were signalled during compilation that were not
handled by the user condition handler (indicating that the output
file may or may not be usable).
(5) Clarify that COMPILE does not establish a condition handler. Instead,
it uses whatever condition handler has been established in the environment
from which it is called.
Rationale:
Point by point,
(1) The new condition types NOTICE and ALERT are structured to allow
this part of the condition hierarchy to be further extended. In
particular, the issue COMPILER-VERBOSITY proposes an additional
subtype of NOTICE named INFO. The description of the NOTICE
function parallels the behavior of WARN.
(2) Conditions such as syntax errors which are errors in the interpreter
remain errors in the compiler. The division of other conditions
into WARNINGs and ALERTs allows potentially serious problems to be
distinguished from mere kibbitzing on the part of the compiler.
(3) It is reasonable for the default handling of compiler errors not to
cause the debugger to be invoked. However, any condition handler
established by COMPILE-FILE would override handlers established by the
user in the surrounding environment.
Requiring the compiler to handle the ABORT restart reflects what
several implementations already do (although probably not using this
mechanism). The intent of the wording is to allow an implementation
to abort the entire file compilation if it is not feasible to abort a
smaller part.
(4) This allows users to determine whether or not COMPILE-FILE is able to
actually compile the file successfully. Returning several values is
is more useful than a single success/failure value because there are
several degrees of failure.
(5) This is to reflect the use of COMPILE-FILE as being more "batch"-oriented
and COMPILE as being more interactive. There is less motivation to have
COMPILE try to recover from errors without user interaction.
Test Case/Example:
An example to illustrate how COMPILE-FILE should set up its condition
handlers is:
(defvar *output-file-truename* nil)
(defvar *errors-detected* nil)
(defvar *warnings-detected* nil)
;;; Call INTERNAL-COMPILE-FILE to do the real work. Note, that function
;;; may set up additional ABORT restarts.
(defun compile-file (input-file &key output-file handler)
(let ((*output-file-truename* nil)
(*errors-detected* nil)
(*warnings-detected* nil))
(with-simple-restart (abort "Abort compilation.")
(handler-bind ((condition #'compile-file-default-handler))
(if handler
(handler-bind ((condition handler))
(internal-compile-file input-file output-file))
(internal-compile-file input-file output-file))))
(values *output-file-truename*
*errors-detected*
*warnings-detected*)))
;;; The default condition handler keeps track of errors and warnings,
;;; and may also perform other implementation-specific actions.
(defun compile-file-default-handler (condition)
(typecase condition
(error
(setq *errors-detected* t)
...)
(warning
(setq *warnings-detected* t)
...)
(alert
...)
))
Current Practice:
No implementation behaves exactly as specified in this proposal.
In VaxLisp, COMPILE-FILE handles most compile-time errors without
invoking the debugger. (It gives up on that top-level form and moves on
to the next one.) Instead of signalling errors or warnings, it simply
prints them out as messages.
In Lucid Common Lisp, COMPILE-FILE invokes the debugger when it encounters
serious problems. COMPILE-FILE returns the pathname for the output file.
Symbolics Genera usually tries to keep compiling when it encounters errors;
so does Symbolics Cloe.
On the TI Explorer, the compiler tries to catch most errors and turn
them into warnings (except for errors on opening a file), but the user
can change special variable COMPILER:WARN-ON-ERRORS to NIL if he wants
to enter the debugger on an error signalled during reading, macro
expansion, or compile-time evaluation. The true name of the output
file is returned as the first value. A second value indicates whether
any errors or warnings were reported.
Cost to implementors:
The cost to implementors is not trivial but not particularly high. This
proposal tries to allow implementations considerable freedom in what
kinds of conditions the compiler must detect and how they are handled,
while still allowing users some reasonably portable ways to deal with
compile-time errors.
Cost to users:
This is a compatible extension. This proposal may cause users to see
some small differences in the user interface to the compiler, but
implementations already vary quite widely in their approaches. Some
users will probably have to make some minor changes to their code.
Adding the new functions and types may cause conflicts with user code
already using those names.
Benefits:
Users are given a way to detect and handle compilation errors, which
would simplify the implementation of portable code-maintenance
utilities. The behavior of the compiler in error situations is made
more uniform across implementations.
Discussion:
The issue of whether the compiler may print normal progress messages
is discussed in detail in a separate issue, COMPILER-VERBOSITY.
The biggest complaint directed against this proposal is that it is much
too complicated.
Kent Pitman suggested an alternate approach:
Specify that COMPILE and COMPILE-FILE return a second value, SUCCESS-P.
Define that compilers are permitted to handle conditions of type ERROR,
turning them into warnings and continuing to compile as appropriate,
but that if an error was turned into a warning so that COMPILE or
COMPILE-FILE could complete its operation, NIL must be returned as the
second value. The normal successful return value would be T.
Loosemore responded:
I'm concerned that besides possibly not being enough to satisfy the
needs of people who are trying to write portable system-building
utilities, this won't do anything to solve the stated problem, namely
how to suppress useless style warning messages.
Some other possible ways of simplifying the proposal include:
- Remove the :HANDLER argument and the requirement that COMPILE-FILE
establish a condition handler and the :HANDLER argument. Continue
to require it to establish an ABORT restart so that user error
handlers established outside the call to COMPILE-FILE can cause
compilation to proceed.
- Put all of the things relating to the NOTICE condition into a
separate proposal, since it's intended to be a more general tool.
- Forget about the NOTICE condition and use STYLE-WARNING (a subtype
of WARNING) instead of ALERT.
Some might wonder why NOTICE is needed instead of just making ALERT a
subtype of WARNING. This is for compatability with other proposed
conditions, notably INFO. While it might be reasonable to say that a
style "warning" is a legitimate WARNING error message, it is really
hard to justify WARNING status for a message like
;;; Starting to compile file foo.
We also contemplated using the name MESSAGE instead of NOTICE, but it
was felt that NOTICE would be less likely to cause conflicts with
existing user code. Another suggestion has been to call the type
NOTIFICATION and the signalling function NOTIFY; some people think
that the name NOTICE might also be too generic.
Pitman says that he would like to require COMPILE-FILE's default
condition handler never to invoke the debugger. I have left that out
of this proposal because it seems like an unnecessary restriction; if
users want to ensure that kind of behavior it is possible to do so by
supplying a user handler. (Of course, the converse is also true.)
Some of the things specified in section 2c as being ALERTS were
described in CLtL as being WARNINGs. There seems to be general
agreement that these things (particularly complaints about unused
variables) are not as serious as other problems described as warnings.
We might consider introducing a COMPILER-CONDITION that can be used in
mixins with the other condition types, so that error handlers can
distinguish between errors signalled by the compiler itself and errors
signalled during macroexpansion or EVAL-WHEN processing. This would
have to wait until the condition system is fully CLOSified.
Possibly NOTICE should write to *STANDARD-OUTPUT*, or even *TRACE-OUTPUT*,
rather than *ERROR-OUTPUT*.
David Gray writes:
This proposal looks good, but there are a couple of little things worrying
me. One is the potentially confusing shift in terminology by which
compiler messages that are conventionally referred to as "warnings", are
now called "alerts", programmer errors are reported as "warnings", and
only what is conventionally called "fatal errors" are reported as "errors".
I don't know what can be done about this, though, since we do want some
down-grading in severity so that the compiler issues a message and continues
for a situation that will signal an error if the compiled code is run.
Probably we just need to be careful how this is documented in order to
minimize confusion.
Another thing is that this doesn't provide a way to suppress style
"warnings" [ALERT conditions] on a local basis. For example, Lisp
Machines have a macro INHIBIT-STYLE-WARNINGS that can be wrapped around a
single form to keep the compiler quiet. I wonder if we might want a
COMPILER-HANDLER-BIND macro for specifying handlers at compile time? This
would be analogous to COMPILER-LET, but it could avoid the problems that
have doomed COMPILER-LET by specifying that the evaluator is free to
ignore it.
∂07-Jan-89 0946 X3J13-mailer **DRAFT** Issue COMPILER-VERBOSITY, version 5
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Jan 89 09:46:19 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA19738; Sat, 7 Jan 89 10:45:11 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA08872; Sat, 7 Jan 89 10:45:08 MST
Date: Sat, 7 Jan 89 10:45:08 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901071745.AA08872@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: **DRAFT** Issue COMPILER-VERBOSITY, version 5
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: COMPILER-VERBOSITY
References: CLtL p. 438-329; 426
issue COMPILER-DIAGNOSTICS
Category: CHANGE/CLARIFICATION/ENHANCEMENT
Edit History: V1, 25 Oct 1988, Sandra Loosemore
V2, 12 Dec 1988, Dan L. Pierson (add USE-CONDITIONS)
V3, 15 Dec 1988, Dan L. Pierson (expand on conditions)
V4, 21 Dec 1988, Dan L. Pierson (reword and clarify)
V5, 06 Jan 1989, Sandra Loosemore (update discussion)
Status: **DRAFT**
Problem Description:
Implementations vary widely in the amount of information that is printed
out by COMPILE-FILE. In some situations, it would be useful to control
how much information is printed.
Proposal COMPILER-VERBOSITY:LIKE-LOAD:
Introduce a special variable, *COMPILE-VERBOSE*, with an implementation-
dependent initial value.
Add :VERBOSE and :PRINT keyword arguments to the function COMPILE-FILE,
analogous to those for the function LOAD.
The :VERBOSE argument (which defaults to the value of *COMPILE-VERBOSE*),
if true, permits COMPILE-FILE to print a message in the form of a comment
to *STANDARD-OUTPUT* indicating what file is being compiled and other
useful information.
The :PRINT argument (which defaults to NIL), if true, causes
information about top-level forms in the file being compiled to be
printed to *STANDARD-OUTPUT*. Exactly what is printed will vary from
implementation to implementation, but nevertheless some information
will be printed.
Rationale:
This proposal makes COMPILE-FILE behave like LOAD. There is already
some precedent for doing this (for example, issue COMPILE-FILE-PACKAGE,
which makes COMPILE-FILE as well as LOAD rebind *PACKAGE*).
Current Practice:
Lucid provides a :MESSAGES keyword argument to COMPILE-FILE, which can
either be a stream to send progress messages to, or NIL to suppress messages.
The default value is T, which sends messages to "the standard terminal
device".
On the TI Explorer, COMPILE-FILE displays the name of the function being
compiled when the option :VERBOSE T is given or special variable
COMPILER:COMPILER-VERBOSE is true. (In other words, they use :VERBOSE
to mean what this proposal says to use :PRINT for.)
Cost to implementors:
This is an incompatible change for some implementations. While the
changes required should be conceptually simple, their implementation
may involve a significant amount of grunt work. At least two
implementations already provide some similar mechanism for suppressing
messages.
Cost to users:
Some (non-portable) user code may break in implementations where this is
an incompatible change.
Specifying that the :PRINT argument defaults to NIL is consistent with
LOAD, but in most implementations the default now is to print out a
lot of information about each function or top-level form. Some users
may find it irritating to have to type in :print t to get the same
amount of information they're used to seeing.
Benefits:
Users are given a portable way to control how much information is printed
by COMPILE-FILE.
Proposal COMPILER-VERBOSITY:USE-CONDITIONS:
Add the new subtype of CONDITION, NOTICE, defined in
COMPILER-DIAGNOSTICS (V5). Add a new subtype of NOTICE, INFO.
Require compilers to "print" all messages covered by this proposal by
using the function NOTICE to signal a condition of type INFO instead
of directly writing the message. For the purposes of this proposal
"compilers" refers to both COMPILE and COMPILE-FILE.
Note that, since a compiler is never required to print any messages
covered by this proposal, no portable program may assume that any
conditions of type INFO will actually be signalled.
Rationale:
This allows informational compiler messages and compiler diagnostics
to be handled in a uniform manner with a simple, well defined way for
the user to gain any desired degree of control over these messages.
Current Practice:
No one currently controls compiler messages via the condition system.
Cost to implementors:
This is an incompatible change for all implementations. It should be
a conceptually simple change to make once an implementation supports
the condition system, however the actual implementation of the change
may involve a significant amount of grunt work.
All existing implementations can continue support their current
message control interfaces as long as the implementation of their
current interface is changed to comply with this proposal. This could
be done by:
1. Causing the old interface to either establish a condition
handler that accepts messages that shouldn't be printed and
does nothing with them. Note that it would not be legal to
make the handler print the messages that should be printed,
because a user handler must still be given a chance to look at
them.
2. Changing the old interface to conditionally write the message
as it used to, except that NOTICE is used to actually write the
message.
Cost to users:
Some user code may break in implementations which remove any
(non-portable) existing mechanisms to control compiler output.
Benefits:
Users are given a portable way to control how much information is printed
by COMPILE-FILE.
Aesthetics:
Using a well defined, already existing, general mechanism is more
aesthetically pleasing than adding another ad-hoc flag or special
variable.
Discussion:
Rather than just treating :PRINT and :VERBOSE as boolean values, it
might be useful to have them convey more information. For example,
Pitman has suggested using keyword values like :BRIEF or :DETAILED to
allow varying amounts of information of each type to be printed.
Alternatively, it might be reasonable to follow Lucid's precedent to
allow the values of :PRINT and :VERBOSE to be streams to allow
messages to be directed somewhere other than *STANDARD-OUTPUT*.
Either of these suggestions could reasonably be made to apply to LOAD
as well, but the intent of LIKE-LOAD is to make COMPILE-FILE
behave like LOAD, not to change the specification of LOAD.
Loosemore questions whether using conditions for this purpose is
appropriate, because this issue deals with messages indicating the
normal progress of the compiler and conditions are supposed to be used
to signal exceptional (non-ordinary) situations.
Pierson believes that conditions provide a well defined, portable,
non-intrusive interface for user control of infrequent events. While
the use of conditions is not notably efficient, compiler informational
messages are sufficiently infrequent that this should not impose a
noticeable performance penalty.
Pierson would like to see LOAD, etc. changed to also use this
interface.
The two proposals are not mutually incompatible in that the LIKE-LOAD
keywords can be added to an implementation whether or not it is based
on USE-CONDITIONS.
∂07-Jan-89 1048 X3J13-mailer issues relating to compiled constants
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Jan 89 10:47:59 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA20410; Sat, 7 Jan 89 11:46:53 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA08916; Sat, 7 Jan 89 11:46:51 MST
Date: Sat, 7 Jan 89 11:46:51 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901071846.AA08916@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: issues relating to compiled constants
Reply-To: cl-compiler@sail.stanford.edu
Coming up shortly will be drafts of four issues relating to the
semantics of quoted and self-evaluating constants:
CONSTANT-COMPILABLE-TYPES
What kinds of objects are dumpable by COMPILE-FILE? What
attributes of those objects must the compiler preserve?
CONSTANT-CIRCULAR-COMPILATION
Must the compiler correctly handle circular objects? Must it
preserve sharing of substructures?
CONSTANT-COLLAPSING
Should the compiler be allowed to use a more general equivalence
relationship than EQUAL in coalescing constants?
QUOTE-MAY-COPY
May COMPILE and EVAL, as well as COMPILE-FILE, substitute
equivalent copies of quoted objects?
All of these issues are very closely related, and the outcome of one
issue may affect each of the others. I apologize for not having a
single document that presents a unified view of the semantics of
constants, but since each of these subissues have been controversial
in their own right (some have competing proposals) it seemed better
not to try to lump them all together. I am hoping that distributing
these writeups to a larger audience will result in some feedback that
will allow us to narrow down the range of possibilities.
-Sandra
∂07-Jan-89 1048 X3J13-mailer **DRAFT** issue CONSTANT-COMPILABLE-TYPES
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Jan 89 10:48:44 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA20422; Sat, 7 Jan 89 11:47:34 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA08919; Sat, 7 Jan 89 11:47:31 MST
Date: Sat, 7 Jan 89 11:47:31 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901071847.AA08919@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: **DRAFT** issue CONSTANT-COMPILABLE-TYPES
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: CONSTANT-COMPILABLE-TYPES
References: CLtL pp. 56, 77-80, 324
Issue CONSTANT-MODIFICATION
Issue CONSTANT-CIRCULAR-COMPILATION
Issue CONSTANT-ARRAY-ATTRIBUTES
Issue QUOTE-MAY-COPY
Issue LOAD-OBJECTS
Category: CLARIFICATION, ADDITION
Edit history: 11/07/88, V1 by Cris Perdue
11/14/88, V2 by Cris Perdue
11/22/88, V3 by Cris Perdue
12/20/88, V4 by Cris Perdue
01/06/89, V5 by Sandra Loosemore (minor editorial
clarifications, expand discussion)
Status: **DRAFT**
Problem description:
CLtL does not specify what objects can be in compiled constants and it
does not say what relationship there can or must be between the
constant passed to the compiler and the one that is established by
compiling and then loading its file. Relevant remarks in CLtL
concerning file compilation and the definition of QUOTE suggest that
the compiler handles constants in ways that are not actually possible.
Introduction to the proposal:
The proposal CONSTANT-COMPILABLE-TYPES:SPECIFY attempts to spell out
what types can appear in compiled constants, and what it means when
they appear. Unless stated otherwise, in this proposal where the term
"constant" is used, it means a quoted or self-evaluating constant, not
a named (defconstant) constant.
The key is a definition of a form of equivalence between Lisp objects,
"similarity as constants". Code passed through the file compiler must
behave as though quoted constants in it are equivalent to quoted
constants in the corresponding interpreted "source" code. This
proposal only concerns quoted constants to be processed by
COMPILE-FILE.
For the benefit of users, this proposal tries to define a fairly large
set of types that all Common Lisp implementations are to handle. It
also attempts to leave room for implementations to differ. Some
implementations have made opposing choices because the language
doesn't specify one over the other. Some implementations already
handle constants that this proposal defines as not legal in Common
Lisp programs, and that is useful to users of those systems.
Different implementors have different amounts of resources to apply to
their system, and implementations differ in their whole approach in
some cases.
We try to set up a framework where some controversies can be defined
clearly and resolved as separate issues.
One of these is the question of when, if ever, to permit "coalescing"
of constants. Some implementations already take advantage of the
license given on page 78 of CLtL to gain some efficiencies. This
proposal provides definitions that make it possible to broaden the
conditions where coalescing is permitted (see related issue
CONSTANT-COLLAPSING).
Another question is whether "circular" constants are compilable (issue
CONSTANT-CIRCULAR-COMPILATION). Most implementations are capable of
supporting circular constants. Still, this proposal avoids requiring
all implementations to handle circular constants. Implementations
that do not handle circular constants presumably also do not make sure
that shared structure remains shared, sort of the opposite of
coalescing. This proposal avoids requiring shared structure to remain
shared across compilation.
Some implementations "lose information" about some constants during
compilation. We try to limit this proposal enough to reduce the
number of unhappy implementors to a bare minimum.
In this version, the question of immutability of some attributes of
objects in compiled constants is not addressed. Cris has taken that
material out of this proposal and is constructing a new proposal
covering just that issue. This proposal does define the concept of
"basic attributes" of various types of objects, and the other proposal
will refer to it, stating that most basic attributes of most types of
objects may be treated as immutable when the object appears in a
compiled constant.
Proposal: CONSTANT-COMPILABLE-TYPES:SPECIFY
An object may be used as a quoted constant processed by COMPILE-FILE
if the compiler can guarantee that the resulting constant established
by loading the compiled file is "similar as a constant" to the
original, plus a few other restrictions.
A few types, such as streams, are not supported in constants. In
other words, an object containing one of these is not considered
similar as a constant to any other object. We say that it is an error
for these objects to appear in a (compiled) constant. Still some
implementations may support them and define how they are treated.
Some types of objects are treated as aggregate objects. For these
types, being similar as constants is defined recursively. We say that
an object of these types has certain attributes, and to be similar as
a constant to another object, the values of the corresponding
attributes of the two objects must also be similar as constants.
This kind of definition has problems with circular or "infinitely
recursive" objects such as a list that is an element of itself. We
consider the idea of depth-limited comparison, and say that two
objects are similar as constants if they are similar at all finite
levels. This idea is implicit in the definitions below, and applies
in all the places where attributes of two objects are required to be
similar as constants.
The rest of this proposal consists of a definition of the notion of
two objects being "similar as constants", organized by type, with some
notes about the additional constraints that the compiler must meet:
Number, Character
If either of two objects is a number or character, the two objects
are similar as constants if and only if they are EQL.
(Note that for cross-compilers it is not always possible to satisfy
this requirement for floating point numbers and complex numbers with
floating point parts. If it is necessary to choose two different
floating point values due to cross-compilation, each value chosen must
be one of the two adjacent, exactly representable numbers such that
the interval between them contains the other number. Other numbers
and characters are represented exactly, so they can be compared if
they are representable on both architecture, an issue for some
characters.)
Random-state
Only the operations PRINT, MAKE-RANDOM, and RANDOM apply to
random-states. Let us say that two random-states are functionally
equivalent if applying RANDOM to them repeatedly always produces the
same pseudo-random numbers in the same order.
Two random-states are similar as constants exactly if copies of them
made via MAKE-RANDOM-STATE are functionally equivalent.
Symbol
A symbol can only be similar to a symbol. References to symbols are
permitted in any constant. References to interned symbols are "by
name". If the symbol is interned, its name and the name of its home
package identify it.
A symbol with a home package is similar as a constant to a symbol when
the names of the symbols and the names of the home packages of the
symbols are similar as constants. (Both symbols must have home
packages.) Within a Common Lisp "address space", this implies that
the symbols are EQ.
If a symbol is not interned, i.e. its home package is NIL, it is
treated in a rather special way. To be similar as a constant to
another symbol, both symbols must be uninterned and have the same
name.
Constants that contain uninterned symbols have to satisfy an extra
constraint. The compiler must arrange that, within a file being
compiled with COMPILE-FILE, references to uninterned symbols that
are EQ in the source code must remain EQ in the compiled code.
Likewise, uninterned symbols that are not EQ must remain non-EQ after
compilation.
Package
A package can only be similar as a constant to a package. References
to packages are permitted in any constant. References to packages are
"by name": two packages are similar as constants when their names are
similar as constants. Within a Lisp "address space", packages with
the same name are EQ.
At load time, the package becomes the same as returned by
FIND-PACKAGE, given the package name. An error is signalled if no
package of that name exists at load time.
OTHER TYPES
-----------
For each of the types listed below, if either object is of the given
type, the two objects are similar as constants exactly if the other is
of that type and the values of all of the specified attributes are
similar as constants.
The attributes listed here can be called the "Basic Attributes" of
objects of each of these types.
Cons CAR, CDR.
Array For 1-dimensional arrays:
LENGTH and ELT for all legal indices.
For arrays of other dimensions:
ARRAY-DIMENSIONS, ARRAY-ELEMENT-TYPE, AREF for all legal
indices.
Note that array constants in a compiled file may lack
displacement, fill pointers, or adjustability, where the
constants in the source had them, but the compiler may
not produce constant arrays that have these features from
ones that do not. The point is to make sure that
declarations are not violated as a result of compilation.
Structure Slot values, name of structure type (a symbol reference).
Hash-table Keys and values. The table's test is of course unchanged
also. It is an error to compile a constant containing a
a hash table that has keys that are similar as
constants.
Readtable Character syntax type for each character in the table;
function for each readmacro character, mappings for
dispatch macros; whether terminating or nonterminating
for each readmacro.
Pathname Each pathname component
Stream, Compiled-Function
It is an error for a stream or compiled-function
to appear in a compiled constant, but the
language may be extended in the future to support certain
cases.
Function Function constants that are not compiled-functions and do
not close over any (lexical) variables are permitted in
compiled constants. Two functions are similar as
constants when they are operationally equivalent. Use of
global function bindings, global macro bindings, and
special variables must be considered external
dependencies for this purpose, and constants appearing in
the functions need only be similar as constants (at level
n-1?).
Generic-function, Method
Help is needed from the CLOS committee to determine what
to do here. (Presumably they would be treated in the same
way as ordinary functions?)
Standard-object
Help is needed from the CLOS committee to determine what
to do here. (There is a cl-cleanup issue, LOAD-OBJECTS,
pending which proposes a mechanism for dealing with
objects.)
Rationale:
This proposal appears to reflect user demand and appears not to exceed
the capabilities of most implementations of the language.
Current practice:
This is believed to be very close to compatible with the Franz, Lucid,
Coral, and Texas Instruments implementations. It is probably
compatible or nearly compatible with other "Lisp Machine"
implementations.
Adoption cost:
Not known. Probably moderate or low -- for most implementations. The
cost would be to implementors rather than users since this part of the
language is currently underspecified. The author believes the cost
will be reasonable for KCL, an implementation where there is some
concern about this issue.
Benefits:
Users would be able to use aggregate objects in constants with
confidence about the behavior of their code.
Conversion cost:
Where this proposal *requires* different behavior than an existing
implementation, there is a conversion cost for users of that
implementation. It appears that this cost will be small, less than
the cost of leaving things unspecified.
Esthetics:
Since there is no adequate definition at present, a fuller definition
would be more esthetic.
Discussion:
This proposal does leave some user-visible attributes of objects
unspecified across the compile-and-load process, except that they must
be consistent with the attributes that must be retained. This
situation is a compromise between the desire for full specification on
the one hand, and on the other hand the desire to leave freedom for
different implementations to remain different and to support some
optimizations such as compacting hash tables and "simplifying" arrays.
Proposals will be entertained for tighter specification of datatypes
such as arrays.
The full extension of the concept of coalescing of constants is to say
that they can be coalesced exactly when they are similar as constants.
Comparing functions is hard. One could define an operation that
converts an interpreted function into a lambda expression. One could
say that interpreted functions are similar as constants when their
associated lambda expressions are similar in the appropriate sense.
This similarity of lambda expressions would be syntactic, but would
have to allow for possible inline macro expansion. Other
transformations would have to be prohibited, or the functions would
have to report themselves as compiled.
This proposal seems to deal with the question of how to test whether
constants in different Lisp address spaces are similar as constants.
That appears to be important.
We need someone expert with floating-point computation to review the
discussion of similarity of floating point numbers as constants.
The definition of similarity for random-states supports the
possibility of random states that are immutable because of being in
compiled constants.
Interest has been expressed by a number of people including users, in
support for user-definable "dumping" of CLOS objects and structure
instances. The cleanup issue LOAD-OBJECTS deals with this.
This subsumes the issue CONSTANT-ARRAY-ATTRIBUTES.
Most of the recent discussion on this proposal has centered around the
handling of functions and readtables, and on aspects relating to CLOS.
Sandra Loosemore notes:
Dumping a constant readtable is not likely to be particularly useful
in an implementation that cannot dump compiled function constants.
(In particular, readtables derived from the standard Common Lisp
readtable are likely to "contain" mostly compiled functions.) I'm
also not convinced that requiring non-compiled, non-closed function
constants buys anything for the user, since an implementation is
always free to make all functions compiled. It seems like it would be
simpler just not to require any function constants to be dumpable.
Jeff Dalton responds:
Although I didn't say anything about it before, I was always bothered
by the idea that functions would be dumped in readtables. Since it's
pretty clear that not all implementations can dump all functions, users
can't rely on it at all; and then the whole idea of dumping a readtable
begins to seem suspect.
JonL White notes:
The analogy between FIND-PACKAGE and FIND-CLASS suggests that class
objects are in the same "database" category as packages. Shouldn't
they be referenced "by name" in compiled file?
Moon responds:
In Flavors we generate metaobjects at compile time, but we never put
them (to speak loosely) into the compiled-code file; instead macros
like DEFFLAVOR and DEFMETHOD expand into Lisp code that obtains new
metaobjects at load time, based on the class name and generic function
name. I don't see how any other way could work, actually, since two
distinct compiled files that refer to a class by the same name must
end up referring to the same metaobject after loading. In Flavors we
don't have anonymous classes nor anonymous generic functions, so we
don't have to solve those issues.
[Issue LOAD-OBJECTS proposes] that the way to load an instance of a
standard-class from a compiled file is for a method of the instance
to return a form which is then evaluated at load time. The semantics
of loading an instance of a standard-class from a compiled file can be
entirely understood in terms of MAKE-INSTANCE or whatever other
function is called by the form returned by MAKE-LOAD-FORM; no new
concepts need be introduced. If the programmer of a given class wants
to use the class redefinition protocol, that class's MAKE-LOAD-FORM
method can output something that uses that protocol, and if he
doesn't, it can output something that doesn't.
∂07-Jan-89 1049 X3J13-mailer **DRAFT** issue CONSTANT-CIRCULAR-COMPILATION
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Jan 89 10:49:17 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA20434; Sat, 7 Jan 89 11:48:08 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA08922; Sat, 7 Jan 89 11:48:05 MST
Date: Sat, 7 Jan 89 11:48:05 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901071848.AA08922@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: **DRAFT** issue CONSTANT-CIRCULAR-COMPILATION
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: CONSTANT-CIRCULAR-COMPILATION
References: Issue CONSTANT-COLLAPSING
Issue QUOTE-MAY-COPY
Category: CLARIFICATION, ADDITION
Edit History: V1, 07 Nov 1988, Sandra Loosemore
V2, 14 Nov 1988, Cris Perdue
V3, 12 Dec 1988, Sandra Loosemore (merge versions 1 and 2)
V4, 03 Jan 1989, Sandra Loosemore (add PRESERVE-SHARING-ONLY)
V5, 06 Jan 1989, Sandra Loosemore (minor wording changes)
Status: **DRAFT**
Problem Description:
CLtL does not specify whether constants containing circular or
recursive references may be compiled. It is also not clear whether
the compiler must preserve sharing of EQ substructures; that is, whether
subobjects that are EQ in the source code must remain EQ after being
compiled.
The proposals below apply to COMPILE-FILE, since it must inherently
copy structures. If issue QUOTE-MAY-COPY is resolved in favor of
allowing COMPILE and possibly EVAL to copy structures, the same
constraints would also apply in those situations. [We would also have
to decide upon the scope over which sharing must be detected in such
situations; the minimal scope would be over a single call to EVAL or
COMPILE.]
In the proposals that follow, "preserving EQness" means that
subobjects that are EQ in the source code must remain EQ after being
compiled; that is, things don't get "less EQ" after compilation.
(Note that coalescing of constants implies that things may get "more
EQ".)
Proposal CONSTANT-CIRCULAR-COMPILATION:NO
State that it is an error for an object containing a circular reference to
appear as a constant to be compiled. State that the compiler is not
required to preserve EQness of substructures.
Rationale:
This proposal would not require any existing implementation to change.
Disallowing portable programs from containing circular constants
allows compiled file loaders to use somewhat simpler implementation
strategies (for example, to build constants in a strict bottom-up
fashion).
Proposal CONSTANT-CIRCULAR-COMPILATION:PRESERVE-SHARING-ONLY
State that it is an error for an object containing a circular
reference to appear as a constant to be compiled. State that the
compiler is required to preserve EQness of substructures within a file
compiled with COMPILE-FILE.
Rationale:
Disallowing portable programs from containing circular constants
allows compiled file loaders to use somewhat simpler implementation
strategies (for example, to build constants in a strict bottom-up
fashion).
Some programs (such as PCL) have come to depend on COMPILE-FILE
preserving the EQness of uninterned symbols, and it is cleaner
to require sharing to be preserved in general instead of making
symbols be a special case. Requiring sharing to be preserved still
allows loaders to build constants bottom-up.
Proposal: CONSTANT-CIRCULAR-COMPILATION:FLAG
Add to the definition of Common Lisp a special variable:
*DUMP-CIRCLE* [Special variable]
State that if the (compile-time) value of *DUMP-CIRCLE* is NIL, it is
an error for an object containing a circular reference to appear as a
constant to be compiled. State that the compiler is required to
preserve EQness of substructures within a file compiled with
COMPILE-FILE when *DUMP-CIRCLE* is non-NIL. (Note that this differs
from *PRINT-CIRCLE*, which is not required to detect sharing.)
The initial value of *DUMP-CIRCLE* is implementation-dependent.
Rationale:
As with *PRINT-CIRCLE* for printing, writing representations of
objects to a stream is much faster if the implementation does not
attempt to support circular, self-recursive, mutually-referential,
etc. substructure.
Current Practice:
A-Lisp preserves EQness of substructures (since it makes an effort to
collapse isomorphic structures) but signals an error if an attempt is
made to compile a circular constant. PSL and Utah Common Lisp both
get stuck in an infinite loop if an attempt is made to compile a
reentrant structure. The TI Explorer compiler is able to reproduce
recursive lists and arrays, but currently hangs in a loop on a
circular list. Lucid and Symbolics can handle circular constants
correctly. Franz uses a flag to control whether or not to attempt to
detect circular constants.
Cost to implementors:
We know of no implementation that would have to change under proposal
NO. For proposal FLAG, some implementations would require sweeping
changes; in some cases a completely different dumper/loader strategy
would have to be implemented. The cost of proposal
PRESERVE-SHARING-ONLY would fall somewhere in between.
Cost to users:
The situation now is that programs which depend upon circularity or
sharing of substructure being preserved by the compiler are already
nonportable. Proposal NO simply formalizes the status quo. Proposal
FLAG would offer users functionality that is currently not portable.
Benefits:
An area of ambiguity in the language is removed.
Discussion:
JonL has argued against proposal CONSTANT-CIRCULAR-COMPILATION:NO, saying
I don't see any performance justification; and even if there were, I'd
look at it with a very jaundiced eye, favoring interpreter/compiler
consistency over nickle-and-dime issues of compiler speed.
Loosemore thinks PRESERVE-SHARING-ONLY is the "right" solution, but
would also support CONSTANT-CIRCULAR-COMPILATION:NO because it is the
most consistent with current practice -- no implementations would be
required to change and no currently portable programs would be
invalidated. While one could make an argument for this proposal on
the basis of improving compiler speed, the compatibility issue is seen
as far more important.
There was also quite a bit of discussion about how this proposal
relates to the requirement in CLtL (p. 69) about preserving the
EQLness of references to symbolic constants.
∂07-Jan-89 1050 X3J13-mailer **DRAFT** issue CONSTANT-COLLAPSING
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Jan 89 10:50:03 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA20460; Sat, 7 Jan 89 11:48:54 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA08925; Sat, 7 Jan 89 11:48:52 MST
Date: Sat, 7 Jan 89 11:48:52 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901071848.AA08925@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: **DRAFT** issue CONSTANT-COLLAPSING
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: CONSTANT-COLLAPSING
References: CLtL p. 78, 87
Issue CONSTANT-MODIFICATION
Issue CONSTANT-COMPILABLE-TYPES
Issue EQUAL-STRUCTURE
Issue QUOTE-MAY-COPY
Category: CHANGE
Edit History: V1, 07 Nov 1988, Sandra Loosemore
V2, 12 Dec 1988, Sandra Loosemore
V3, 03 Jan 1989, Sandra Loosemore
V4, 06 Jan 1989, Sandra Loosemore
Status: **DRAFT**
Problem Description:
CLtL states that an implementation is permitted to "collapse" or
coalesce constants appearing in code to be compiled if they are EQUAL.
The definition of EQUAL does not permit coalescing of more general
isomorphic data structures (such as arrays and structures), which is
often desirable.
Issue QUOTE-MAY-COPY deals with whether coalescing may be performed
only by COMPILE-FILE, or by COMPILE and EVAL as well. CLtL says: "An
object is considered to be a constant in code to be compiled if it is
a self-evaluating form or contained in a QUOTE form".
Proposal CONSTANT-COLLAPSING:GENERALIZE:
State the an implementation is permitted to "collapse" constants
appearing in code to be compiled if they are equivalent under the
relationship specified in issue CONSTANT-COMPILABLE-TYPES.
Rationale:
There is little reason why implementations should not be allowed to
perform more general collapsing of structures, since the arguments
against doing so also apply to collapsing of EQUAL structures, which
is already permitted.
Current Practice:
Both PSL/PCLS and A-Lisp collapse isomorphic arrays and structures,
and certain other data types that are defined internally as structures
(RANDOM-STATEs, for example). Lucid Common Lisp also uses a more
general coalescing predicate than EQUAL.
Cost to implementors:
None. This extends the range of permitted behavior for
implementations but does not require any implementation to change.
Cost to users:
It is hard to imagine a program that would break under this proposal.
Benefits:
Collapsing of isomorphic arrays and structures may lead to significant
memory savings in some applications.
Discussion:
This proposal depends heavily on issue CONSTANT-COMPILABLE-TYPES.
Some people believe that if the definition of EQUAL weren't "broken",
there wouldn't be any need for this proposal.
There is no inherent reason why the "coalescing predicate" must be the
same as the relationship used by the compiler/loader to construct
equivalent copies of objects of constants, but making the same rules
be applied in both situations simplifies the language somewhat.
∂07-Jan-89 1050 X3J13-mailer **DRAFT** issue QUOTE-MAY-COPY
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Jan 89 10:50:37 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA20465; Sat, 7 Jan 89 11:49:27 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA08928; Sat, 7 Jan 89 11:49:24 MST
Date: Sat, 7 Jan 89 11:49:24 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901071849.AA08928@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: **DRAFT** issue QUOTE-MAY-COPY
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: QUOTE-MAY-COPY
References: CLtL p. 55, 78, 86, 143
Issue CONSTANT-COLLAPSING
Issue CONSTANT-COMPILABLE-TYPES
Issue CONSTANT-MODIFICATION
Category: CHANGE/CLARIFICATION
Edit History: V1, 5 Dec 1988, Sandra Loosemore
V2, 10 Dec 1988, Sandra Loosemore
(comments from Dalton, JonL)
V3, 3 Jan 1989, Sandra Loosemore
(comments from Pitman et al)
V4, 7 Jan 1989, Sandra Loosemore
(update discussion)
Status: **DRAFT**
Problem Description:
May QUOTE return a copy of its argument? In particular, is it
permissible for COMPILE to copy quoted constants to read-only
memory, or to coalesce equivalent constants?
In spite of the name of this issue, the question is not whether QUOTE
itself may copy objects, but whether the semantics of "quoted objects"
is such that it is permissible for the compiler or interpreter to
substitute a copy of the original object.
Background:
CLtL p. 86 states that (QUOTE <x>) simply returns <x>. On
p. 55 it is mentioned that the only self-evaluating forms that may
be copied are numbers or characters. It is also stated that an
implementation is permitted to collapse (or coalesce) EQUAL constants
appearing in code to be compiled.
Because of its nature as a file processor, COMPILE-FILE generally must
cause copies of constants to be constructed when the compiled code is
loaded. In a number of existing Lisp implementations, COMPILE also
causes constant objects to be copied and/or coalesced. Since it is
permissible for an implementation to implicitly compile even
"interpreted" code (p. 143), the semantics of constants seen by EVAL
may also be affected if the in-memory compiler (as well as the file
compiler) is allowed to copy or coalesce constants.
The arguments for allowing constants to be copied can be summarized
briefly as follows. Copying constants to read-only memory can result
in less work for garbage collectors. If there is hardware support for
write-protection of memory, this may also be used to cause an error to
be signalled if an attempt is made to modify the constant. Coalescing
equivalent constants can lead to significant memory savings in some
applications (although this savings is likely to be less for individual
functions compiled with COMPILE than entire programs compiled with
COMPILE-FILE).
The primary argument against allowing constants to be copied or
coalesced is that doing so causes information to be lost, and in the
case of COMPILE and EVAL, there is no inherent reason why this
information must be discarded. Some people also feel that allowing
QUOTE not to return a value that is EQ (or even EQL) to its argument
would be a substantial, incompatible change from its "traditional"
semantics.
Proposal QUOTE-MAY-COPY:ALWAYS:
Change the description of QUOTE to indicate that (QUOTE <x>) returns
an object equivalent to <x>, which may or may not be EQ to <x>.
Likewise, a self-evaluating form may also return an equivalent copy
of the object.
The equivalence relationship is defined in the writeup for issue
CONSTANT-COMPILABLE-TYPES, and only those objects for which this
relationship is defined may appear as quoted or self-evaluating
constants. The restrictions placed on compiled constants in
issue CONSTANT-CIRCULAR-COMPILATION apply to constants in code
processed by EVAL and COMPILE, as well as COMPILE-FILE. EVAL and
COMPILE may also coalesce constants, as described in issue
CONSTANT-COLLAPSING.
If an implementation chooses to copy constants, the copying may only
happen once each time the form containing the constant is processed
with COMPILE or EVAL (see examples below).
Rationale:
This proposal would make the treatment of constants uniform across
COMPILE-FILE, COMPILE, and EVAL.
Proposal QUOTE-MAY-COPY:NOT-EVAL-OR-COMPILE:
Clarify that self-evaluating forms and quoted constants always
evaluate to objects that are EQL to the original, except in the case
of code compiled with COMPILE-FILE (where an equivalent but possibly
non-EQL object is returned). The restrictions on compiling constants
in issues CONSTANT-COMPILABLE-TYPES and CONSTANT-CIRCULAR-COMPILATION
apply only to COMPILE-FILE. Only COMPILE-FILE may coalesce constants
(issue CONSTANT-COLLAPSING).
Rationale:
This proposal is the most consistent with the semantics described in
CLtL. It would make the treatment of constants uniform across
COMPILE and EVAL.
Proposal QUOTE-MAY-COPY:NOT-EVAL:
Clarify that quoted or self-evaluating constants appearing in code
processed by EVAL must return an object that is EQL to the original.
In functions that have been compiled with COMPILE or code that has
been compiled with COMPILE-FILE, an equivalent (but possibly
non-EQL) copy of the object may be returned instead.
The equivalence relationship is defined in the writeup for issue
CONSTANT-COMPILABLE-TYPES, and only those objects for which this
relationship is defined may appear as quoted or self-evaluating
constants in code to be compiled. The restrictions on constants
described in issue CONSTANT-CIRCULAR-COMPILATION apply to both
COMPILE-FILE and COMPILE, and both may coalesce constants as
described in issue CONSTANT-COLLAPSING. There are no restrictions
on what kinds of objects may appear in code processed with EVAL, and
EVAL may not coalesce equivalent constants.
If an implementation chooses to copy constants, the copying may only
happen once each time the form containing the constant is processed
with COMPILE (see examples below).
Rationale:
This proposal is the most consistent with current practice.
Test Cases/Examples:
#1: (Behavior of COMPILE)
Suppose the function FOO is defined:
(defun foo () '(a b c))
Under all three proposals, multiple calls to FOO must always return
EQ values, regardless of whether FOO is interpreted or compiled:
(eq (foo) (foo)) ==> true
Proposals ALWAYS and NOT-EVAL allow FOO to return a "different" EQ
value after it is compiled:
(setq old-foo (foo))
(compile 'foo)
(eq old-foo (foo)) ==> ??? under ALWAYS or NOT-EVAL
true under NOT-EVAL-OR-COMPILE
#2: (Behavior of EVAL)
(let ((x '(a b c)))
(eq x
(eval (list 'quote x))))
Under proposal ALWAYS, this may or may not return true. Proposals
NOT-EVAL-OR-COMPILE and NOT-EVAL guarantee this to return true.
(let ((x '(a b c)))
(eq (eval (list 'quote x))
(eval (list 'quote x))))
Under proposal ALWAYS, this may or may not return true (each call to
EVAL may construct its own copy of X). Proposals NOT-EVAL-OR-COMPILE
and NOT-EVAL guarantee this to return true.
Current Practice:
Implementations in which COMPILE copies constants include PSL/PCLS and
Kyoto Common Lisp. In Lucid Common Lisp, constants are not normally
copied by COMPILE, but since COMPILE does coalesce constants, it may
cause QUOTE to return an object which is not EQL to its original
argument.
There do not appear to be any implementations in which constants are
copied by EVAL.
Cost to implementors:
Proposal QUOTE-MAY-COPY:NOT-EVAL-OR-COMPILE would cause significant
problems for some implementations. For example, PSL/PCLS would
require major changes to its memory management scheme and garbage
collector as well as the compiler to bring it into compliance.
Proposal QUOTE-MAY-COPY:NOT-EVAL could potentially cause problems for
compiled-only implementations in which the in-memory compiler normally
coalesces or makes copies of constants. There does not appear to be
any existing implementation that would be affected.
Note that neither QUOTE-MAY-COPY:ALWAYS or QUOTE-MAY-COPY:NOT-EVAL
-require- constants to be copied or coalesced; neither proposal would
require changes to those implementations that currently don't touch
constants.
Cost to users:
Proposals QUOTE-MAY-COPY:ALWAYS and QUOTE-MAY-COPY:NOT-EVAL would have
the result of explicitly stating that programs which depend on COMPILE
preserving EQLness of constants are nonportable. (This is the de
facto situation now.) Such programs could continue to work in those
implementations in which COMPILE does not copy or coalesce constants.
The impact of allowing constants to be copied in interpreted code
(proposal QUOTE-MAY-COPY:ALWAYS) is unknown. It could be argued that
any code that depends on constants not being copied or coalesced is
broken, since it would not work when compiled in some implementations.
Benefits:
The semantics of QUOTE are clarified.
Discussion:
There has been some confusion about the names of the proposals. It's
been suggested that all of the proposals should be rewritten and
renamed to make it more clear that the issue is whether COMPILE or
EVAL may make copies of constants. Note that proposal
QUOTE-MAY-COPY:ALWAYS implies that copying is always *permitted*, but
is not required under any circumstances.
This issue has caused a very lengthy debate on the cl-compiler mailing
list, with no consensus arising yet. Following are comments
summarizing various people's positions.
Kent Pitman originally supported NOT-EVAL-OR-COMPILE, but now says:
I asked Moon about his feelings on this. He thinks pretty strongly that
the ALWAYS option is the only practical one to pursue. Partly, he says,
because it's maximally compatible with current practice and partly
because it avoids making COMPILE-FILE seem different.
In principle, I favor option ALWAYS, permitting copying of quoted
structure to a constants area in any of EVAL, COMPILE, or COMPILE-FILE
situations, as appropriate to the implementation.
It should not be concluded from this that I favor restrictions on the
kinds of data which may be quoted, however. The wording of option ALWAYS
should be ammended to say that such copying is permitted only when the
system can reliably deduce whether such copying is `appropriate,'
and avoid it in cases where it is not. The purpose of such wording would
be to avoid placing restrictions on what kinds of structures a user can
or cannot quote.
So, for example, if an implementor cannot in some context figure out how
to detect circularities in quoted structure in order to either decline
copying or correctly copy the circular form, then the implementation is
not permitted to attempt copying in such contexts.
Note however that because of special considerations forced by the external
representation of data in compiled files, I go along with (and encourage)
the establishment of a known subset of types which can be quoted (or used
as self-evaluating constants) in code to be reliably processed by the file
compiler. Coincidentally, such restrictions might make it easier for an
implementation to know whether copying was going to succeed in the case of
loading compiled code from a file, but technically these restrictions are
not motivated by any consideration of what kinds of structures might or
might not be possible to QUOTE.
My inclination is also to believe that copying should not be done
repeatedly, and we should find a way to express this. That is, repeated
execution of code in the same execution environment should return an EQL
result (or some such). This is important to guaranteeing efficiency. Even
in copying implementations, it is not necessary that such constants be
allocated in a read-only area or some such to achieve this effect. For
example, quoted structure could be placed in a special array and QUOTE
could be implemented using AREF. What is important is that any of these
permissions we give for copying not be taken for a license that QUOTE
should be implemented by COPY-TREE or some other operation which cannot
be done in constant time.
Dan Pierson says:
I also support QUOTE-MAY-COPY:NOT-EVAL-OR-COMPILE. In the absence of
overwhelming opposing reasons, we should not diminish traditional Lisp
functionality. While NOT-EVAL may be more in line with current
practice of a couple of implementations, the argument that these
implementations are already broken is at least as strong as the
argument that we shouldn't break them by pointing out that they don't
conform to the language standard.
However, my position on this is not unalterable.
Sandra Loosemore says:
I oppose NOT-EVAL-OR-COMPILE on the grounds that it differs from current
practice and would involve a substantial conversion cost for some
implementations; either of the other two alternatives would be acceptable
instead since they involve essentially no conversion cost for either
implementors or users. I am not convinced that the modifications to
proposal ALWAYS suggested by Pitman wouldn't cause just as much work
for some implementations as forbidding copying entirely. If the
modifications applied only to the behavior of EVAL and not COMPILE, that
would be OK.
Many people have referred to "tradition" in their arguments on this
issue. Different implementations have different traditions, and what
seems "broken" to one person may seem perfectly natural to another
person who comes from a different background.
JonL White says:
I favor giving as much leeway as possible to
the implementors for making memory-management optimizations. While one
implementor may choose not to do any such work, and another may even go
out of his way to assure EQLness over an unlikely set of circumstances,
this should not constrain the third from doing the "classic" thing. In
short, I don't see the value of adding constraints that
(1) invalidate much existing practice, and
(2) appear to be purely of theortical value.
Making "compiled code" (read: compile-file) work as closely as possible to
interpreted code is _not_ "purely of theortical value."
QUOTE-MAY-COPY:ALWAYS is the only proposal that both recognizes the
prevalent practice and pays (at least) lip service to the question of
compiled/interpreted consistency.
Cris Perdue says:
I am opposed to all of the proposals offered in their current
form.
CLtL takes a simple, useful approach to this problem. The idea
that QUOTE cannot reasonably operate as defined in CLtL is incorrect,
though it appears desirable to explain somewhere the "copying"
effects that compile-file may have on constants.
To say that QUOTE copies in existing implementations is to
imply that a lot of copying might happen that never actually
happens. COMPILE-FILE followed by LOAD effectively copies,
and in KCL, COMPILE effectively makes a copy, but not QUOTE.
I object strongly to suggestions that QUOTE copies in existing
practice, at least existing practice as I know it. Among other things,
this skews the entire discussion. It also limits the set of datatypes
that can be QUOTEd, because the equivalence defined in
CONSTANT-COMPILABLE-TYPES does not support all datatypes.
It is possible for QUOTE or a garbage collector to copy
constants into readonly storage, but I think that rationale is
different from supporting existing practice. With that rationale
I might support something like QUOTE-MAY-COPY:ALWAYS, but I think
it would be questionable whether the equivalence defined in
CONSTANT-COMPILABLE-TYPES is sufficient. A version
that applies to all objects might be advisable as the equivalence
maintained by QUOTE.
∂07-Jan-89 1311 X3J13-mailer **DRAFT** issue EVAL-WHEN-NON-TOP-LEVEL, version 4
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Jan 89 13:11:33 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA23183; Sat, 7 Jan 89 14:10:25 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA08982; Sat, 7 Jan 89 14:10:22 MST
Date: Sat, 7 Jan 89 14:10:22 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901072110.AA08982@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: **DRAFT** issue EVAL-WHEN-NON-TOP-LEVEL, version 4
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: EVAL-WHEN-NON-TOP-LEVEL
References: CLtL p. 69-70
Issue DEFINING-MACROS-NON-TOP-LEVEL
Category: CHANGE, CLARIFICATION
Edit History: 6-May-88, V1 by Sandra Loosemore
16 Dec 1988, V2 by Sandra Loosemore (alternate direction)
30 Dec 1988, V3 by Sandra Loosemore (minor wording changes)
07 Jan 1989, V4 by Sandra Loosemore (update discussion)
Status: **DRAFT**
Problem Description:
The current description of how the compiler should handle EVAL-WHEN
only makes sense when it appears as a top-level form in the file being
compiled. Is it legitimate for EVAL-WHEN to appear in non-top-level
locations? What does it mean in such places?
Proposal EVAL-WHEN-NON-TOP-LEVEL:IGNORE-COMPILE:
Clarify that EVAL-WHEN may appear both at top-level and at
non-top-level. In non-top-level locations, however, the COMPILE
situation is effectively ignored.
More specifically, when an EVAL-WHEN form is processed by the
interpreter (that is, by the function EVAL), the presence of the EVAL
situation indicates that the body of the EVAL-WHEN should be evaluated
as an implicit PROGN. Otherwise, EVAL-WHEN returns NIL without
evaluating the body. The interpreter ignores the COMPILE and LOAD
situations.
When an EVAL-WHEN form is processed by the compiler:
First, if the situation COMPILE is specified:
- If the EVAL-WHEN form appears at top level (as defined in
proposal DEFINING-MACROS-NON-TOP-LEVEL:ALLOW), then each of
the forms within the body of the EVAL-WHEN are evaluated by
the compiler in the null lexical environment using the
function EVAL.
- Otherwise, no compile-time evaluation takes place. An
implementation is permitted to signal a warning to indicate
that the compile-time evaluation is being ignored.
Then, if the situation LOAD is specified, then the compiler treats
the body of the EVAL-WHEN form as if it were an implicit PROGN.
If the situation LOAD is not specified, then the compiler should
treat the EVAL-WHEN form as if it were a constant value of NIL.
The compiler ignores the EVAL situation.
Rationale:
Restricting compile-time evaluation to top-level locations prevents
complications resulting from performing the evaluation in the wrong
lexical environment.
This definition of how EVAL-WHEN behaves is much simpler than that
given in CLtL, and makes it easier to explain its nesting behavior.
Allowing implementations to signal a warning when ignoring a
non-top-level EVAL-WHEN allows users to be informed that something
unusual is going on.
Current Practice:
IIM Common Lisp implements this proposal. Kim Barrett contributed the
following code that illustrates their implementation:
(defmacro eval-when (situations &body body &environment env)
(if (not (compiler-environment-p env))
(when (member 'eval situations) `(progn ,@body))
(progn
(when (member 'compile situations)
(if (compiler-at-top-level-p env)
(mapc #'eval body)
(warn "Top-level form encountered at non-top-level.")))
(when (member 'load situations) `(progn ,@body)))))
Cost to implementors:
Probably fairly minor in most implementations.
Cost to users:
Except for the change relating to possible multiple evaluation of
nested EVAL-WHENs, this proposal is a compatible extension.
Benefits:
The behavior of EVAL-WHEN is easier to understand. Making EVAL-WHEN
meaningful at non-top-level locations makes it more generally useful,
for example in the expansion of defining macros.
Discussion:
The behavior specified for top-level EVAL-WHENs in this proposal
differs slightly from that described in CLtL. In the case where both
COMPILE and LOAD are specified, CLtL indicates that the compile-time
evaluation should be interleaved with normal compiler processing of
each of the forms in the body, while this proposal specifies that the
evaluation of all of the body forms should take place before any of
the normal compiler processing. However, it is unlikely that this
would cause serious problems for any user programs.
The nesting behavior of EVAL-WHEN as described in CLtL has been
criticized as overly complicated and hard to understand, while this
proposal is much less complicated. However, the behavior of nested
EVAL-WHENs in this proposal is strongly tied to the definition of the
term "top-level"; see proposal DEFINING-MACROS-NON-TOP-LEVEL:ALLOW.
If the bodies of top-level EVAL-WHENs are also considered to be
top-level, this leaves open the possibility that nested EVAL-WHENs may
cause multiple compile-time evaluations. For example,
(eval-when (eval compile load)
(eval-when (eval compile load)
(punch-paper-tape)))
would cause PUNCH-PAPER-TAPE to be called twice at compile time (once when
the outer EVAL-WHEN is processed, and again when the inner EVAL-WHEN is
processed). Some people think this behavior would be unacceptable.
This problem could be "fixed" by not considering the bodies of top-level
EVAL-WHENs to be top-level forms. In this case, outer EVAL-WHENs would
always override any nested EVAL-WHENs. For example,
(eval-when (eval load)
(eval-when (eval compile load)
(punch-paper-tape)))
would not cause *any* compile-time call to PUNCH-PAPER-TAPE. This
represents an incompatible change from the behavior of EVAL-WHEN
described in CLtL, where wrapping a form with (EVAL-WHEN (EVAL LOAD)
...) is essentially a no-op. Some people think the change would be a
good idea, others are uncertain whether the resulting cleaner
semantics would justify it.
As a compromise position, we could say that EVAL-WHEN passes
top-level-ness on to its body only if the COMPILE situation is not
specified.
Some people are not comfortable with messing with the definition of
top-level at all. On the other hand, others think it is important
that EVAL-WHEN and the various defining macros should apply consistent
rules for deciding when it is appropriate to perform compile-time
magic.
A final alternative is to go back to describing EVAL-WHEN the way it
was in CLtL, with a compile-time-too state variable.
∂07-Jan-89 1316 X3J13-mailer **DRAFT** issue DEFINING-MACROS-NON-TOP-LEVEL, version 7
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 7 Jan 89 13:12:18 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA23191; Sat, 7 Jan 89 14:11:10 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA08985; Sat, 7 Jan 89 14:11:06 MST
Date: Sat, 7 Jan 89 14:11:06 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901072111.AA08985@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: **DRAFT** issue DEFINING-MACROS-NON-TOP-LEVEL, version 7
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: DEFINING-MACROS-NON-TOP-LEVEL
References: CLtL p. 66-70, 143
Issue EVAL-WHEN-NON-TOP-LEVEL
Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Issue COMPILER-LET-CONFUSION
Category: CLARIFICATION, ENHANCEMENT
Edit History: 6-May-88, V1 by Sandra Loosemore
9-Jun-88, V2 by Sandra Loosemore
12-Sep-88, V3 by Sandra Loosemore (fix garbled section 4)
21-Sep-88, V4 by Sandra Loosemore (clarify section 5)
16-Dec-88, V5 by Sandra Loosemore (major restructuring)
31-Dec-88, V6 by Sandra Loosemore (wording clarifications)
07-Jan-89, V7 by Sandra Loosemore (add example)
Status: **DRAFT**
Problem Description:
CLtL leaves the interpretation of defining forms such as DEFMACRO and
DEFVAR that appear in other than top-level locations unclear.
On page 66, it is stated: "It is not illegal to use these forms at
other than top level, but whether it is meaningful to do so depends on
context. Compilers, for example, may not recognize these forms
properly in other than top-level contexts". At least one implementation
has interpreted this to mean that it is permissible to simply refuse
to compile defining macros that do not appear at top-level.
Proposal: DEFINING-MACROS-NON-TOP-LEVEL:ALLOW
(1) Remove the language from p. 66 of CLtL quoted above. Clarify that
while defining macros normally appear at top level, it is meaningful
to place them in non-top-level contexts and that the compiler must
handle them properly in all situations. However, the compile-time side
effects described in issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
only take place when the defining macros appear at top-level.
(2) Remove the language on p. 145 of CLtL, which states that macro
functions are always defined in the null lexical environment. Clarify
that all defining macros which create functional objects (including
DEFMACRO, DEFTYPE, DEFINE-SETF-METHOD, and the complex form of
DEFSETF, as well as DEFUN) must ensure that those functions are
defined in the lexical environment in which the defining form is
evaluated.
(3) Define a ``top-level form'' as follows:
- Each form read by COMPILE-FILE from the input file is a top-level
form.
- Forms within the body of a top-level PROGN, EVAL-WHEN, or
COMPILER-LET are also top-level forms.
- The expansion of a top-level macro call is also a top-level form.
Top-level forms would be evaluated by the interpreter in a null
lexical environment, but evaluation in a null lexical environment does
not necessarily imply that the form is top-level.
(4) Specify that top-level forms in a file being compiled are
guaranteed to be processed sequentially, including forms within the
body of a top-level PROGN, EVAL-WHEN, or COMPILER-LET. The order in
which non-top-level subforms of a top-level form are processed by the
compiler is explicitly left unspecified.
Rationale:
The notion of a ``top-level form'' is rather confused, since the term
is used in CLtL to refer both to a place where a form may appear (what
this proposal continues to call ``top-level''), and to instances of
forms which traditionally appear there (what this proposal calls
``defining macros'').
There has been a suggestion that the notion of a top-level form should
be extended to include forms in the body of a top-level LET, to allow
forms such as DEFUN to be meaningful there. However, we feel that a
cleaner solution is to remove the restrictions on the placement of
defining macros altogether.
Item (4) serves two purposes. First, it guarantees users that
compile-time side-effects from top-level EVAL-WHEN forms or defining
macros will happen in the correct order. Second, it allows compilers
to perform certain kinds of source-to-source transformations that
change the order of subforms.
For instance, the following example from CLtL
(let ((old-count *access-count*))
(unwind-protect
(progn
(incf *access-count*)
(perform-access))
(setq *access-count* old-count)))
is entirely equivalent to:
(let ((old-count *access-count*))
(let ((thunk #'(lambda () (setq *access-count* old-count))))
(unwind-protect
(progn
(incf *access-count*)
(perform-access))
(funcall thunk))))
(This is a real example from the A-Lisp compiler, which implements
UNWIND-PROTECT by having it push a "thunk" to perform the cleanup
actions onto the catch stack before executing the protected form.)
Current Practice:
CLtL mentions only that forms within a top-level PROGN, and not
COMPILER-LET, are treated as top-level. However, COMPILER-LET is
also treated specially in implementations derived from the MIT Lisp
Machine (TI and Symbolics), as well as Lucid and Coral (but not
VaxLisp).
Cost to implementors:
Implementations that currently don't compile defining macros correctly
when they appear at non-top-level will have to be changed.
Cost to users:
None. This is a compatible extension.
Benefits:
The notion of defining macros as being somehow special when they
appear at top-level is removed. Allowing defining macros to appear
anywhere instead of restricting them to certain positions results in a
cleaner language design.
Discussion:
This proposal is consistent with the behavior specified in proposal
EVAL-WHEN-NON-TOP-LEVEL:IGNORE-COMPILE. In particular, if the compile
time side-effects for defining macros specified in proposal
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY are implemented using
EVAL-WHEN, the "right" compiler behavior for defining macros at
non-top-level will happen automatically.
The issue of whether the bodies of top-level EVAL-WHENs should also be
considered top-level is controversial, as it effects the nesting
behavior of EVAL-WHEN. See issue EVAL-WHEN-NON-TOP-LEVEL for details.
There has also been a suggestion that MACROLET bodies should be
considered top-level. IIM Common Lisp implements this.
Note that proposal COMPILER-LET-CONFUSION:ELIMINATE would remove
COMPILER-LET from the language entirely.
∂08-Jan-89 2342 CL-Compiler-mailer **DRAFT** issue CONSTANT-COMPILABLE-TYPES
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 8 Jan 89 23:41:53 PST
Return-Path: <barmar@Think.COM>
Received: from kulla.think.com by Think.COM; Mon, 9 Jan 89 02:35:59 EST
Received: by kulla.think.com; Mon, 9 Jan 89 02:38:15 EST
Date: Mon, 9 Jan 89 02:38:15 EST
From: barmar@Think.COM
Message-Id: <8901090738.AA09372@kulla.think.com>
To: cl-compiler@sail.stanford.edu
Cc: x3j13@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Sat, 7 Jan 89 11:47:31 MST <8901071847.AA08919@defun.utah.edu>
Subject: **DRAFT** issue CONSTANT-COMPILABLE-TYPES
The full extension of the concept of coalescing of constants is to say
that they can be coalesced exactly when they are similar as constants.
I guess my last message can be thought of as endorsing this idea.
barmar
∂09-Jan-89 0848 X3J13-mailer Editorial committee issues
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 9 Jan 89 08:48:01 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA15007; Mon, 9 Jan 89 08:46:48 PST
Message-Id: <8901091646.AA15007@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 9 Jan 89 11:44
To: x3j13@sail.stanford.edu
Subject: Editorial committee issues
The editorial committee has completed discussion of 5 issues and
would like to bring them to vote, if possible, in Hawaii. Although
there will be copies available in Hawaii, please review these issues
and send comments to cl-editorial.
Thanks for your time.
kathy chapman
∂09-Jan-89 0849 X3J13-mailer Issue:DEPRECATION-POSITION
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 9 Jan 89 08:49:26 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA15093; Mon, 9 Jan 89 08:48:13 PST
Message-Id: <8901091648.AA15093@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 9 Jan 89 11:47
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue:DEPRECATION-POSITION
Issue: DEPRECATION-POSITION
References: X3J13 committee and sub-committee meetings
Category: Policy
Edit history: 12-DEC-88, Version 1 by Chapman
20-DEC-88, Version 2 by Chapman
9-JAN-89, Version 3 by Chapman
Problem Description:
When features of a language become outdated due to technology advances,
or unnecessary due to the addition of better features, should the old
features be deprecated from the language, or deleted outright?
Since there has never been a Common Lisp standard before, deprecation
is against a de-facto standard, which may or may not be appropriate.
Deletion, on the other hand, is cleaner, but may generate never-ending
discussion when the standard goes for public review (and even in the
X3J13 meeting).
In summary, there are two levels:
1) features in CLtL that are not present in ANSI Common Lisp 1989,
2) features in ANSI Common Lisp 1989 that will likely not be present in
future standards;
and the issues are:
a) what features fit into which category
b) how should implementations deal with such features? how can programs be
written to avoid problems with such features?
Proposal (DEPRECATION-POSITION:LIMITED)
Since Common Lisp has been used industrially, it is reasonable to
assume that any level 1 feature will be a cause for
at least some controversy. Therefore, this proposal suggests that
X3J13 put features categorized as level 1 in a separate package,
and retain features categorized as level 2 in the Lisp package, but
declare them deprecated in the standard.
The members of each level will be determined on a case-by-case basis by
the X3J13 committee.
Rationale:
The standard should contain information about deprecation since
the topic has been mentioned more than once in X3J13, and since
Common Lisp is such a large language.
It's not
unreasonable for a language the size of Lisp to get rid of the
never-used tools, but we don't want to generate years of discussion
over a relatively minor issue when the standard goes for public review.
Current Practice:
Fortran successfully deprecated one constant. However, a proposal
submitted during its latest standardization effort that
suggested deleting old features in favor of new ones was
opposed vehemently. The Pascal committee is currently opposed
to deprecation, and the SPARC proposal suggests that
deprecation should be dictated by the marketplace.
Adoption Cost:
None.
Benefits:
This policy will provide a basis for future X3J13 decisions.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
Comment:
"I personally would argue for not including "deprecated" features in
the standard at all, because including them now will make it harder to
remove them later. My perception is that ANSI Common Lisp is turning
out to be a much different language than what is described in CLtL,
particularly if CLOS becomes a required part of the language. If,
with the benefit of hindsight and experience, we now realize that some
"features" described in CLtL were really "bugs", the time to remove
them is *before* they become cast in stone as part of ANSI Common
Lisp. I suspect that most implementors will continue to provide these
features as extensions anyway, as long as a substantial number of
their customers are still using them."
Response:
Perhaps most implementors will continue to provide the deleted features,
but they will do that also if they are deprecated. Since the only real
difference between the two is the amount of discussion one will generate
over the other (I think that worrying about future difficulty of getting
rid of the features is not a "real" difference yet), it seems that choosing
the route of least resistance in this case is the wisest course.
Comment:
"For the most part, X3J13 hasn't been able to deal with
which features fit into which category until how the categories will
be divided has been resolved. In particular, there are a number of
features that we didn't want to remove from ANSI Common Lisp 1989 if
it would be awkward for implementations to continue to support them or
programs to continue to use them, but wanted to at least declare them
"obsolete". There's been some debate on whether CHAR-FONT, for
example , should be deleted before the standard is written, or declared
deprecated within the standard."
∂09-Jan-89 0851 X3J13-mailer Issue:CUT-OFF-DATES
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 9 Jan 89 08:50:53 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA15165; Mon, 9 Jan 89 08:49:39 PST
Message-Id: <8901091649.AA15165@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 9 Jan 89 11:49
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue:CUT-OFF-DATES
Issue: CUT-OFF-DATES
References: Working draft of the standard
Category: Policy
Edit history: 20-DEC-88, Version 1 by Chapman
9-JAN-89, Version 2 by Chapman
Problem Description:
The X3J13 committee has informally agreed that a 12/89 standard is
a doable goal. However, the standard has to be reviewed by a large
number of people outside the X3J13 committee. We must allow plenty
of time for these reviews, and should therefore plan our internal
reviews and "document freeze" accordingly.
Proposal (CUT-OFF-DATES:ESTABLISH)
Item Cut-off date for changes
________________________________________________(First day of the month)____
Format of tool descriptions 11/88
Meaning of each item in each tool description 11/88
Fonts 2/89
Changes to existing functions 4/89
Additional functions 4/89
Compliance 2/89
Error terms 2/89
Contents of Chapter 6 tool descriptions:
- Syntax section 2/89
- Arguments section 5/89
- Values section 5/89
- Description section 5/89
- Examples section 2/89
- Side Effects section 3/89
- Affected By section 3/89
- Conditions section 4/89
- See Also section 2/89
- Notes section 5/89
Changes to TOC 2/89
Contents of sections: 4/89
- 1.1 4/89
- 1.2 4/89
- 1.3 4/89
- 1.4 4/89
- 1.5 4/89
- 1.6 4/89
- 1.7 4/89
- 1.8 4/89
- 2.1 5/89
- 2.2 5/89
- 2.3 5/89
- 2.4 5/89
- 2.5 5/89
- 3.1 5/89
- 3.2 5/89
- 4.1 6/89
- 4.2 6/89
- 5.1 6/89
- 5.2 6/89
- 5.3 6/89
- 5.4 6/89
The way this breaks down is as follows:
Things that have already frozen: format of Chapter 6 tool descriptions,
meaning of each tool description category.
Things that will be frozen after the 1/88 meeting: fonts, compliance,
error terms, syntax section, examples section, see also section,
side effects section, affected by section, table of contents, and
this schedule of cut-off dates.
Things that will be frozen after the 3/88 meeting:
Contents of Chapters 1, 2, and 3, New issues that change existing functions
or add new functions, values section, arguments section, description
section, notes section, and conditions section.
Things that will be frozen by 6/1/89:
Chapters 4 and 5.
All comments received according to this schedule will be incorporated
by 6/30/89. Any comments received after the dates listed above will
only be considered if they are of an extreme nature, if they impact
the correctness of the document. Otherwise the comments will be filed
and reserved for the next standard.
To change these dates, a 2/3 vote of the editorial committee
or a majority vote of X3J13 is required.
Rationale:
In order to complete this standard and move on to the next version,
we need to establish dates after which changes will not be allowed.
Current Practice:
None.
Adoption Cost:
None.
Benefits:
Establishing cut-off dates will encourage reviewers to complete
a thorough review in a timely manner.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
Comment:
"There are a couple of areas where I expect some further work that might
impact these dates:
a) pathname functions
I'm still hoping to get some cleanup of many of the pathname issues
b) errors signalled, by name
I'm still hoping that we can get at least a partial listing, for each
function, of the possible errors signalled, under what circumstances.
c) pending cleanups
There will probably be 10-15 cleanup issues dealing with ambiguities that
will drag out beyond 3/89. I hope not, but I'm trying to be realistic;
there are just too many "open" issues left."
∂09-Jan-89 0851 X3J13-mailer Issue:SUBSETTING-POSITION
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 9 Jan 89 08:51:25 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA15185; Mon, 9 Jan 89 08:50:10 PST
Message-Id: <8901091650.AA15185@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 9 Jan 89 11:49
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue:SUBSETTING-POSITION
Issue: SUBSETTING-POSITION
References: X3J13 committee and sub-committee meetings
Category: Policy
Edit history: 12-DEC-88, Version 1 by Chapman
9-JAN-89, Version 2 by Chapman (with discussion by Masinter)
Problem Description:
Should the CL standard be partitioned such that an implementation
could chose a subset of all the CL facilities to implement and
still be a conforming implementation?
What subsets should be specified in the draft standard we submit to
ANSI?
What position should we take if someone should propose a subset?
Proposal (SUBSETTING-POSITION:NONE)
The draft standard we submit to ANSI
contains *no* subsets. In the section on "subsetting" it should be mentioned
that Lisp is a "small" language with a "big" library and that the conventional
mechanism for allowing small memory images is auto-load.
Rationale:
Current Practice:
Pascal has two levels of conforming implementations -- level 1 contains
level 0 and conformant arrays. This was a compromise necessary to achieve
international agreement. The 1981 PL/I was subsetted and the
results were a range of implementations between the
subset and the full language; nobody wanted to use the subset so vendors
were forced to implement the full language eventually anyway.
Cobol had multiple levels of subsets. However,
the only two levels that were important were the minimum
subset and the full language. The middle levels were
seldom used other than transient points to the full language.
Fortran was subsetted. It was felt that subsetting encouraged
vendors to implement Fortran and therefore proliferate its usage,
but users were quite annoyed that one Fortran was considerably
different from another.
The new Fortran language standards committee is
banning subsetting.
SPARC feels that
subsets aren't good for facilitating interchange, but serve the
purpose of allowing
timely implementation of the standard.
A suggestion that was made by most language committee representatives
was to group subsetted parts meaningfully, and to minimize the number
of levels.
Adoption Cost:
None.
Benefits:
This policy will provide a basis for making decisions in X3J13.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
First of all, we should review the possible kinds of subsets one might
have: subsets might omit syntax, functions, admissable values or arguments
to functions, or data types. For example, a subset might disallow SPECIAL
declarations (a syntactic subset), might omit the COS, SIN, ATAN functions,
might disallow the :TEST keyword to MAKE-HASH-TABLE, might restrict TAILP
to work on proper lists, or might omit complex numbers. Each of these is a
"subset" in the sense that a subset of correct programs for the "full"
language would be correct for the "subset" language.
Subsets can have various levels of "determinability" for programs. The
issue is: how easy is it to tell whether a program written in the "full"
language would run in a "subset" implementation? Except for the
(non-trivial) issue of macro expansions, some subsets are "lexically"
determinable, e.g., if a function is omitted, you can tell if the program
uses it by scanning the program. Some subsets are "dynamically"
determinable, e.g, a subset might signal an error if the :TEST argument to
MAKE-HASH-TABLE is EQUALP. Some subsets are neither lexically nor
dynamically determinable, e.g., if the subset implements dynamic extent for
rest lists, it may be impossible to tell even with run-type checks whether
the a program written in the "full" language would conform.
Some "subsets" might be merely restrictive interpretations, e.g., a
"run-time" implementation that made ED, TRACE, UNTRACE into no-ops and made
BREAK halt the program execution rather than "enter the debugger"; since we
cannot define what "enter the debugger" means, we might want to define
explicitly this subset as a reasonable one for embedded systems.
∂09-Jan-89 0852 X3J13-mailer Issue:CONFORMANCE-POSITION
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 9 Jan 89 08:52:34 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA15368; Mon, 9 Jan 89 08:51:17 PST
Message-Id: <8901091651.AA15368@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 9 Jan 89 11:50
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue:CONFORMANCE-POSITION
Issue: CONFORMANCE-POSITION
References: Chapter 1, Section 1.5, Working draft of standard
Category: Clarification
Related Issues: EXTENSIONS-POSITION, LISP-SYMBOL-REDEFINITION, PACKAGE-CLUTTER
Edit history: 12-DEC-88, Version 1 by Chapman
20-DEC-88, Version 2 by Chapman
9-JAN-89, Version 3 by Chapman
Problem Description:
Two ways of defining conformance are in terms of a conforming program
and in terms of a conforming implementation. How should our standard
define conformance?
Proposal (CONFORMANCE-POSITION:PROGRAM)
The standard presents the syntax and semantics to be implemented by
a conforming implementation.
A conforming program is one that can be executed by a conforming
implementation with no unhandled exceptions and no unspecified
and potentially harmful consequences.
The basic test for conformance will be that a program written to the letter
of the standard will run in all "conforming" implementations.
The basic rules are as follows:
. Conforming programs use the syntax described in the standard.
. Conforming programs are written using the functions, macros,
special forms, variables, constants described in the standard.
. Conforming implementations provide the functions, macros, special
forms, variables, constants, and arrange that they behave in ways
that conform to the descriptions of them in the standard.
Rationale:
The standard must contain information about conformance. Including
requirements which would be placed on implementations, however, leaves
the possiblity open that something would be overlooked, and so
implementations may well conform without processing correctly
conforming programs.
Current Practice:
CLtL generally describes things in terms of what a correct program can
expect.
dpANS C is also in terms of programs. They have further defined
both "conforming" and "strictly conforming" programs; the
difference has something to do with how the program deals with features
that the standard says are implementation-defined.
Pascal defines
conformance in terms of both, PL/I defines conformance in terms of
conforming programs only.
Fortran and Ada say that a conforming implementation correctly processes
conforming programs. Ada goes on to say other specific things about
a conforming implementation, Fortran does not at this time but probably
will in its next standard. The ISO conformance guidelines, and the
draft of the SPARC proposal discuss both programs and implementations.
Adoption Cost:
None.
Benefits:
This definition will give readers and validators a basis on which to read
the standard.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
Comment:
I think we might want to introduce the notion of a "portable" program, as
well as a "conformal" one.
A "portable Common Lisp program" is a conformal Common Lisp program that
"works the same" in all conformal implementations.
Response:
There should be no difference, then between a portable program and a
conforming program. Why introduce new terms?
∂09-Jan-89 0933 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu URGENT: Northeastern University Theory Day - Corrections
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Jan 89 09:31:30 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA21303; Mon, 9 Jan 89 09:30:38 PDT
Message-Id: <8901091730.AA21303@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Mon, 9 Jan 89 09:30:51 PST
Received: by BYUADMIN (Mailer R2.01A) id 6239; Mon, 09 Jan 89 10:29:12 MST
Date: Mon, 9 Jan 89 09:34:51 EST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
andrew klapper <klapper%CORWIN.CCS.NORTHEASTERN.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
From: andrew klapper <klapper%CORWIN.CCS.NORTHEASTERN.EDU@Forsythe.Stanford.EDU>
Subject: URGENT: Northeastern University Theory Day - Corrections
Comments: To: theorynt@vm1.nodak.edu
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
-------------------------------------------------------------------------------
The College of Computer Science at Northeastern University
announces its 1989
THEORY DAY
Friday, January 27, 1989
........................... Schedule of Events ................................
10:00 AM Eric Allender "Limitations of the Upward Separation Technique"
11:00 AM Joan Feigenbaum "Generating Hard Certified Elements of
NP-Complete Sets"
12:00 PM Lunch Break
2:00 PM Gilles Brassard "Minimum Disclosure Proofs of Knowledge"
3:30 PM Ken MacAloon "Constraint Logic Programming"
All talks will take place in room 356 Ell Center on the Northeastern University
campus. Parking on campus will be available but requires prior approval. For
information about visitor parking and maps of campus or for any other
information, please contact Gayle Mackay:
College of Computer Science
Northeastern University
360 Huntington Ave.
Boston, MA 02115
(617) 437-2464
or contact Andy Klapper at klapper@corwin.ccs.northeastern.edu
∂09-Jan-89 0939 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Urgent: Semantics of Programming Languages
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Jan 89 09:39:06 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA21580; Mon, 9 Jan 89 09:38:28 PDT
Message-Id: <8901091738.AA21580@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Mon, 9 Jan 89 09:38:41 PST
Received: by BYUADMIN (Mailer R2.01A) id 6523; Mon, 09 Jan 89 10:34:04 MST
Date: Mon, 9 Jan 89 10:12:21 EST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Gyorgy Revesz 789-7871 <REVESZ%YKTVMH.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
From: Gyorgy Revesz 789-7871 <REVESZ%YKTVMH.BITNET@forsythe.stanford.edu>
Subject: Urgent: Semantics of Programming Languages
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
The Programming Languages and Foundations Department
of the IBM T.J. Watson Research Center
Announces a series of distinguished lectures on the
----------------------------------------------------------------------------
SEMANTICS OF PROGRAMMING LANGUAGES
----------------------------------------------------------------------------
January 26 An ultimate "Kahn Principle" for dataflow semantics
Albert Meyer, MIT
----------------------------------------------------------------------------
February 23 How far do we need to automate proofs?
Dana Scott, Carnegie Mellon University
----------------------------------------------------------------------------
March 23 Denotational semantics and observable properties
Samson Abramsky, Imperial College
----------------------------------------------------------------------------
April 27 To be announced
John Mitchell, Stanford University
----------------------------------------------------------------------------
May 25 Type structure and categories
John Reynolds, Carnegie Mellon University
----------------------------------------------------------------------------
Location:IBM T.J. Watson Research Center, Hawthorne, NY
Time: 3 PM - 4 PM
Visitors are welcome. Please make arrangements
in advance by contacting Gyorgy Revesz at
(914) 789-7871.
IBM T.J. Watson Research Center
P.O. Box 704
Yorktown Heights, NY 10598
∂09-Jan-89 0943 LOGMTC-mailer Seminar reminders
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Jan 89 09:43:36 PST
Received: by csli.Stanford.EDU (4.0/4.7); Mon, 9 Jan 89 09:42:06 PST
Date: Mon 9 Jan 89 09:42:05-PST
From: Sol Feferman <SF@CSLI.Stanford.EDU>
Subject: Seminar reminders
To: Logic@csli.Stanford.EDU
Message-Id: <600370925.0.SF@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
Today at 4:15 PM Prof. Gabriel Stolzenberg of Northeastern U will give a
special lecture on constructive mathematics. Tomorrow at 4:15 Paolo
Mancosu will continue a presentation of his work on generalizing classical
and effective analogues for model theory. Both in Room 381-T.
No meeting January 17.
-------
∂09-Jan-89 1132 @Score.Stanford.EDU:chandler@polya.Stanford.EDU General Faculty Meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Jan 89 11:32:37 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 9 Jan 89 11:29:36-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA21752; Mon, 9 Jan 89 09:42:14 PDT
Date: Mon, 9 Jan 1989 9:42:06 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, bureaucrats@score
Subject: General Faculty Meeting
Message-Id: <CMM.0.87.600370926.chandler@polya.stanford.edu>
Just a reminder...tomorrow - 1/10 - General Faculty Meeting to be held at
2:30 in MJH-146.
∂09-Jan-89 1149 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Tomorrow's Faculty Lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Jan 89 11:49:43 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 9 Jan 89 11:46:49-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA00390; Mon, 9 Jan 89 11:47:14 PDT
Date: Mon, 9 Jan 1989 11:45:31 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, bureaucrats@score
Subject: Tomorrow's Faculty Lunch
Message-Id: <CMM.0.87.600378331.chandler@polya.stanford.edu>
Just a reminder......tomorrow's faculty lunch to be held in the Hartley
Conference Room of the Mitchell Earth Sciences Building at 12:15 will feature
Rebecca Lasher of the Math/CSD Library demonstrating on-line access to
library materials.
∂09-Jan-89 1155 X3J13-mailer Issue:EXTENSIONS-POSITION
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 9 Jan 89 11:55:13 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for skona%csilvax@hub.ucsb.edu; id AA15119; Mon, 9 Jan 89 08:48:49 PST
Message-Id: <8901091648.AA15119@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 9 Jan 89 11:48
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue:EXTENSIONS-POSITION
Issue: EXTENSIONS-POSITION
References: Chapter 1, Working draft of standard
Category: Clarification
Related Issues: CONFORMANCE-POSITION, IF-BODY
Edit history: 12-DEC-88, Version 1 by Chapman
20-DEC-88, Version 2 by Chapman
9-JAN-89, Version 3 by Chapman
Problem Description:
What is the definition of a language extension?
What effect does a language extension have on a conforming program?
What obligation does an implementation have to warn the user that an
extension is being used?
Is it OK to define Common Lisp functions with extra optional or
keyword parameters, with system dependent meanings? E.g. Lucid's
COMPILE-FILE has several keyword arguments not mentioned in CLtL.
Is it OK to return extra values from Common Lisp functions?
Is it OK to define the behavior of functions on datatypes not
explicitly permitted in CLtL? For example, suppose + is defined on
vectors to do component-wise addition on the elements? Arguments to +
"must" be numbers, meaning that it "is an error" to supply anything
other than numbers, meaning that anything can happen when you supply
arguments other than numbers.
Proposal (EXTENSIONS-POSITION:DOCUMENTATION)
The standard document should define a language extension to be
any implementation-supplied tool that isn't explicitly defined
in the standard. This includes facilities added to tools defined
in the standard.
The standard document should levy the following requirement on a
conforming implementation's documentation:
The documentation that accompanies a conforming implementation should clearly
state which parts of the implementation are extensions.
Extensions that are associated with symbols that are external in the LISP
package are reasonable. Extensions to existing functions
as far as additional optional or keyword arguments are disallowed,
except where explicitly allowed. Extensions to existing functions as far as
data types allowed, extra arguments, or extra return values are disallowed
except where explicitly allowed.
If the standard says that "the results are unspecified", and an
implementation specifies the results, this an extension in the
sense that if the correct behavior of a program depends on the results,
only implementations with the same extension will execute the program
correctly.
Rationale:
The standard should contain information about language extensions
since most implementations have extended the language.
Current Practice:
CLtL allows any extension, provided that it doesn't alter the behavior
of a program that only uses what is specified in CLtL. In particular,
any situation that "is an error" (either explicitly or implicitly) is a
potential area for extension.
Adoption Cost:
Vendors will have to improve their documentation
to list all their extensions. Vendors will have to go through their
implementation and determine what is or isn't an extension.
Benefits:
This definition will provide a basis for proper understanding of
the error terminology used in the standard. The implementation
documentation requirement will aid the user in producing portable code.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
Comments:
"The most commonly proposed solution to this kind of problem is to
require the implementation to have a way to disable its extensions, so
that a programmer can be told when he is using a feature that might
affect his program's portability. Whether this should be the default
mode is up for debate; I think most other standards that do this don't
require it to be the default."
Response:
Requiring an implementation to be able to disable extensions seems like
a more costly alternative than requiring an implementation to document
its extensions as extensions if it is to be conforming, since presumably
an implementation will document user-visible extension anyway.
Comment:
It seems to be a constraint on "documentation" rather than "implementation"
if you turn the accidental behavior of (CAR T) into a "feature" of your
implementation. We might want to disallow such an extension as "conforming
to the standard". An implementation which had such an extension might
conform, even if the extension did not conform.
Response:
There are currently statements in the conformance section of the standard
that state what you have demonstrated here. They will be left in that
section.
∂09-Jan-89 1242 X3J13-mailer Re: Issue:SUBSETTING-POSITION
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 9 Jan 89 12:41:24 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa06734; 9 Jan 89 19:42 GMT
Date: Mon, 9 Jan 89 19:43:21 GMT
Message-Id: <11708.8901091943@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue:SUBSETTING-POSITION
To: chapman <@decwrl.dec.com:chapman@aitg.dec>, x3j13@sail.stanford.edu
In-Reply-To: chapman's message of 9 Jan 89 11:49
Subsetting has long been a somewhat controversial topic, but I think
it is fair to say that "no subsets" is the dominant position in X3J13.
It is possible that subsets might be helpful at the ISO level, but
so far the idea of a subset (without any other changes) has not attracted
too great a following.
> Proposal (SUBSETTING-POSITION:NONE)
>
> The draft standard we submit to ANSI contains *no* subsets. In the
> section on "subsetting" it should be mentioned that Lisp is a "small"
> language with a "big" library and that the conventional mechanism for
> allowing small memory images is auto-load.
I'd be happier if it were fairly easy for someone reading the standard
to determine which part was the "library" and which the core language.
For example, where do we find FUNCALL and APPLY?
The draft C standard has an explicit division. Section 3 is
"Language" and section 4 is "Library". It may not be necessary
to go that far for Common Lisp.
> Current Practice:
>
> The 1981 PL/I was subsetted and the results were a range of
> implementations between the subset and the full language; nobody wanted
> to use the subset so vendors were forced to implement the full language
> eventually anyway.
I'd be interested in knowing more of the PL/I story. As I recall, we
(Dartmouth) were quite happy with "Subset G".
I suppose you might want to add something about Basic. At one point,
there was an ANSI standard for "Minimal Basic". It was too minimal.
Later work on ANSI Basic involved a rather different-looking language
(think "structured control structures") and a number of optional
extensions for such things as real-time process control. I don't
know the details or what finally happened, but it looked fairly messy.
∂09-Jan-89 1257 lansky@ai.sri.com AIRR Seminar Reminder
Received: from Warbucks.AI.SRI.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89 12:56:21 PST
Received: from venice.ai.sri.com by Warbucks.AI.SRI.COM with INTERNET ;
Mon, 9 Jan 89 12:44:33 PST
Received: by venice.ai.sri.com (3.2/4.16)
id AA00773 for planlunch@ai.sri.com; Mon, 9 Jan 89 12:44:36 PST
Date: Mon 9 Jan 89 12:44:34-PST
From: LANSKY@Warbucks.AI.SRI.COM (Amy Lansky)
Subject: AIRR Seminar Reminder
To: planlunch@Warbucks.AI.SRI.COM
Message-Id: <600381874.0.LANSKY@VENICE.ARPA>
Mail-System-Version: <SUN-MM(229)+TOPSLIB(128)@VENICE.ARPA>
VISITORS: Please arrive 5 minutes early so that you can be escorted up
from the E-building receptionist's desk. Thanks!
-----------------------------------------------------------------------
ABDUCTION, DEDUCTION, INDUCTION AND PREDICTION
John R. Josephson (Josephson@osu-20.ircc.ohio-state.edu)
Ohio State University Laboratory for AI Research (LAIR)
Department of Computer and Information Science
2:00 PM, TUESDAY, January 10
SRI International, Building E, Room EJ228
Abduction has been described as a distinctive form of inference,
separate from both deduction and induction. Other terms that have
been used for essentially the same inference pattern include:
inference to the best explanation, hypothetic inference, eliminative
induction, differential diagnosis, and the explanatory inference. It
is the ``hypothetico-'' in the ``hypothetico-deductive'' model of the
scientific method, and often the ``hypothesize'' in the ``hypothesize
and test'' weak method in AI. The objectives of this talk will be to
describe and characterize abductive inference, and to clarify some
relationships to deduction and induction. In particular I will argue
that some abductions are deductions, but some are not, and that
inductive generalizations can be insightfully analyzed as special
cases of abductions. I will argue that predictions are a distinctive
form of inference; they are not abductions and are sometimes
deductive, sometimes not. The result will be a new taxonomy of basic
inference types.
-------
∂09-Jan-89 1303 X3J13-mailer revised ISO discussion, revised DRAFT Gegenda and Subcommittee meetings
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 9 Jan 89 13:03:27 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00910g; Mon, 9 Jan 89 12:59:24 PST
Received: by challenger id AA16753g; Mon, 9 Jan 89 12:55:22 PST
Date: Mon, 9 Jan 89 12:55:22 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8901092055.AA16753@challenger>
To: x3j13@sail.stanford.edu
Subject: revised ISO discussion, revised DRAFT Gegenda and Subcommittee meetings
Guest Room 120 of the hotel has been reserved for Subcommittee meetings.
Please let me know how much time you need and what day and time you'll need.
I'll make up a scudule and post it.
---jan---
Monday, January 16
7:30am - ISO discussion, Chart room
We've found copying facilities to be very expensive at hotels. We intend not
to use their facilities. Please mail copies of reports to Liz Anne's
attention at the hotel if you intend to distribute reports to the meeting.
Participants are encouraged to bring copies of reports mailed to them to the
meeting.
X3J13 Committee Meeting Agenda DRAFT
January 16 - 18, 1988
1 Call to Order, January 16, 9:00am Chart Room
2 Opening Remarks and Introductions
- Opening Remarks, Bob Mathis (10 minutes)
- Introduction of attendees
- Future meetings, Jan Zubkoff (5 minutes)
3 Approval of Agenda
4 Approval of Minutes
5 Other Business
6 Character Subcommittee Report, Thom Linden (2 hours)
7 Coffee Break 10:30
8 Character continuation
9 Chapter 3 CLOS, Gregor Kiczales (1 hour)
10 LUNCH 12:00 Voyage Room Restaurant
11 Compiler Subcommittee, Sandra Loosemore (2 hours)
12 Iteration Subcommittee Report, Jonl White (30 minutes) 89-004
13 Recess 3:00
14 Call to Order, 8:00pm
15 Editorial Subcommittee Report, Kathy Chapman (1 hour)
16 Other Subcommittee Reports
16a Recess 10:00
17 Call to Order, January 17, 9:00am Chart Room
18 Other Subcommittee Reports
19 Coffee Break 10:30am
20 Cleanup Subcommittee, Larry Masinter
21 Lunch 12:00 Voyage Room Restaurant
22 Cleanup continuation
23 Break 3:00
24 Cleanup continuation
25 Recess 4:30pm
26 Luau 6:45pm
27 Call to Order, January, 18 9:00am Paddle Room
28 Cleanup continuation
29 Coffee Break 10:30
30 Cleanup continuation
31 Lunch, 12:00 Voyage Room Restaurant
32 Cleanup continuation
33 Recess, 3:00pm
34 Call to Order, January, 18 7:00pm
35 Cleanup continuation
36 Adjournment
∂09-Jan-89 1607 @polya.Stanford.EDU:dill@amadeus.Stanford.EDU Harry Lewis Talk
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Jan 89 16:07:19 PST
Received: from Amadeus.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA19697; Mon, 9 Jan 89 16:05:29 PDT
Received: by amadeus.Stanford.EDU (5.59/inc-1.0)
id AA08327; Mon, 9 Jan 89 16:04:42 PDT
Date: Mon, 9 Jan 89 16:04:42 PDT
From: dill@amadeus.Stanford.EDU (David Dill)
Message-Id: <8901100004.AA08327@amadeus.Stanford.EDU>
To: lop@polya.stanford.edu
Subject: Harry Lewis Talk
SPECIAL SEMINAR
11:00 AM
Thursday, January 19, 1989
Margaret Jacks 252
This talk should be of interest not only to theoreticians, but
also to those interested in timing in circuits and other systems.
A LOGIC OF CONCRETE TIME INTERVALS
AND
THE ANALYSIS OF CIRCUITS WITH BOUNDED TEMPORAL UNCERTAINTY
Harry R. Lewis
Gordon McKay Professor of Computer Science
Harvard University
As the complexity of circuit designs continues to increase, the utility
of simulation and debugging tools to validate those designs continues
to decrease. Almost no tools are available that provide formal verification
of even small asynchronous circuit designs, under models of circuit
function comparable to those used by engineers when doing designs.
We propose a model of asynchronous boolean circuits (with
feedback) in which the response time of an individual logical element
is known within concrete time bounds (e.g. ``the rise time is between
110ns and 140ns''). We develop a theory of nondeterministic finite-state
machines that captures exactly the range of possible logical and temporal
behaviors of such devices. These abstract machines are in turn the natural
models for formulas of a temporal logic with modalities for assertions
about concrete times (e.g. ``if A can become true within 200ns, then
necessarily B will become true within 50ns thereafter'').
This logic (or syntactically convenient extensions of it) can be used
for formally specifying circuit functionality. Such specifications
can be mechanically checked against proposed designs that use
subtle coincidences of timing in order to work (or fail).
We will mention some possible extensions of the circuit model, as
well as some possible applications of the logic and its model
theory to the analysis of other systems of asynchronous events.
∂09-Jan-89 1632 @polya.Stanford.EDU:tah@linz MTC Seminar
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Jan 89 16:32:31 PST
Received: from linz.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA21336; Mon, 9 Jan 89 16:31:07 PDT
Received: by linz.stanford.edu (5.59/25-eef) id AA17415; Mon, 9 Jan 89 16:26:11 PDT
Message-Id: <8901100026.AA17415@linz.stanford.edu>
To: lop@polya
Subject: MTC Seminar
Reply-To: tah@cs.stanford.edu
Date: 09 Jan 89 16:26:09 PST (Mon)
From: Tom Henzinger <tah@linz>
There will be no seminar on January 13, because many participants will
be at POPL. We'll continue this quarter Fridays at noon, starting on
January 20. I'll send out a message about topics next week.
-- Tom.
∂09-Jan-89 1705 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Urgent: Invited Lecture
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Jan 89 17:05:46 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA23062; Mon, 9 Jan 89 17:05:04 PDT
Message-Id: <8901100105.AA23062@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Mon, 9 Jan 89 17:05:17 PST
Received: by BYUADMIN (Mailer R2.01A) id 3601; Mon, 09 Jan 89 18:03:19 MST
Date: Mon, 9 Jan 89 15:41:52 EST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Gyorgy Revesz 789-7871 <REVESZ%YKTVMH.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
From: Gyorgy Revesz 789-7871 <REVESZ%YKTVMH.BITNET@forsythe.stanford.edu>
Subject: Urgent: Invited Lecture
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
The Programming Languages and Foundations Department of the
IBM T.J. Watson Research Center
Announces the fisrt invited talk in a series of
distinguished lectures on the Semantics of Programming Languages
TITLE: An Ultimate 'Kahn Principle' for Dataflow Sementics.
SPEAKER: Alber Meyer, MIT
DATE: January 26, 1989
LOCATION: IBM T.J. Watson Research Center, Hawthorne, N.Y.
TIME: 3 PM - 4 PM
-----------------------------------------------------------------------
A B S T R A C T
Kahn showed in the mid-70's that dataflow nets whose nodes process inputs
"sequentially" AND "functionally" can be analyzed by fixed-point
reasoning on the domain of data-streams. On the other hand,
Brock-Ackermann observed in the late 70's the ``anomaly'' that for
nondeterministic nodes such as MERGE, the data-stream input-output
behavior of the nodes did not even uniquely determine the behavior
of nets using such nodes.
We report on some notable progress on the mathematical semantics of
dataflow nets made recently by independent groups at Tel Aviv, MIT,
and Cornell.
For example, Kahn's Least-Fixed Point Principle can now be extended
to nets with non-sequential functional nodes, and Brock-Ackermann's
anomaly can be culled from essentially any nonfunctional nodes. This
case study also illustrates the significance of such basic concepts
in programming semantics as compositionality, observational congruence,
and full abstraction.
-----------------------------------------------------------------------
Visitors are welcome. Please, make arrangements in advance by contacting
Gyorgy Revesz at (914) 789-7871
∂09-Jan-89 1712 @polya.Stanford.EDU:ARCEO@Warbucks.AI.SRI.COM SEMINAR - JANUARY 11th (Wednesday)
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Jan 89 17:12:41 PST
Received: from Warbucks.AI.SRI.COM by polya.Stanford.EDU (5.59/25-eef) id AA23583; Mon, 9 Jan 89 17:11:02 PDT
Resent-Message-Id: <8901100111.AA23583@polya.Stanford.EDU>
Return-Path: <ARCEO@Warbucks.AI.SRI.COM>
Date: Fri 6 Jan 89 14:22:47-PST
From: ARCEO@Warbucks.AI.SRI.COM (Dori Arceo)
Subject: SEMINAR - JANUARY 11th (Wednesday)
To: AIC-Staff@Warbucks.AI.SRI.COM, planlunch@Warbucks.AI.SRI.COM,
CSL-Staff@CSL.SRI.COM, BBoard@KL.SRI.COM
Cc: Waldinger@Warbucks.AI.SRI.COM
Message-Id: <600128567.0.ARCEO@WARBUCKS.AI.SRI.COM>
Mail-System-Version: <VAX-MM(229)+TOPSLIB(126)@WARBUCKS.AI.SRI.COM>
Resent-Date: Mon 9 Jan 89 17:08:04-PST
Resent-From: WALDINGER@Warbucks.AI.SRI.COM (Richard Waldinger)
Resent-To: lop@POLYA.STANFORD.EDU
TITLE: Refinement of Data
SPEAKER: Prof. Ralph Back
Department of Computer Science
Abo Akademi
Turku, Finland
TIME: 4:15 Wednesday, January 11
PLACE: AI Center Conference Room
EJ 228
Building E, SRI International
ABSTRACT:
The refinement calculus gives a formal basis for the stepwise-refinement
method of program construction. It is an extension of the weakest-precondition
calculus of Dijkstra, and is based on a relation of refinement between program
statements. This relation is a partial order when the semantics of statements
is identified with their predicate transformers. The talk describes how to
handle data refinement within this calculus, i.e., how to change the data
representation within a program in a systematic manner by a sequence of
correctness-preserving program transformations. The method proposed can also
handle nondeterministic abstraction functions (cases where a concrete program
state may represent many different abstract states). This is achieved by
introducing statements with an angelic (don't know) nondeterminism, in
addition to the usual demonic (don't care) nondeterminism assumed by Dijkstra.
The resulting specification/programming language is given a game-theoretic
weakest-precondition semantics. The method permits different representations
of a data abstraction to coexist in a program statement, using explicit
representation and abstraction statements to move from one representation to
another.
-------
∂09-Jan-89 2246 misha@polya.Stanford.EDU Next AFLB
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Jan 89 22:46:31 PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA03687; Mon, 9 Jan 89 22:45:11 PDT
Date: Mon, 9 Jan 89 22:45:11 PDT
From: Michael Kharitonov <misha@polya.Stanford.EDU>
Message-Id: <8901100645.AA03687@polya.Stanford.EDU>
To: aflb-all@polya.Stanford.EDU
Subject: Next AFLB
AFLB is going to be eventful and exciting this quarter.
It looks like in addition to the regular time we will need
an alternative slot. Tuesdays at 4:15 pm seems like a good
choice; if anybody objects to this time, please let me know.
We will kick off with a talk by Don Knuth at the same bat-time
(Thursday, Jan 12, 12:30) and bat-place (MJH 352):
Title: Stable Husbands
(joint work with Rajeev Motwani and Boris Pittel)
Abstract:
Suppose $n$ boys and $n$ girls rank each other at random. We show that any
particular girl has at least $({1\over 2}-\epsilon) \ln n$
different husbands in the set of all Gale/Shapley stable matchings defined
by these rankings, with probability approaching~1 as $n→∞$, if $\epsilon$
is any positive constant. The proof emphasizes general methods that appear
to be useful for the analysis of many other combinatorial algorithms.
∂10-Jan-89 0817 TAJNAI@Score.Stanford.EDU Reminder of Sunrise Club breakfast on Tuesday, 1/17
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Jan 89 08:17:45 PST
Date: Tue 10 Jan 89 08:01:22-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Reminder of Sunrise Club breakfast on Tuesday, 1/17
To: faculty@Score.Stanford.EDU, ras@Score.Stanford.EDU, phd@Score.Stanford.EDU
Message-ID: <12461452196.15.TAJNAI@Score.Stanford.EDU>
TO: Faculty, Research Assistants, and PHD students
FROM: Carolyn Tajnai
RE: Sunrise Meeting, Jan. 17, 1988
The next Sunrise Club meeting will be on Tuesday,
January 17, 1989, same place, same time - Tresidder
Union, Oak Lounge West at 7:30 a.m. The speaker
will be Dr. R. Fabian Pease of the Electrical
Engineering Department whose lecture is titled
"The Impact of Micro-miniaturization on Electronics."
Please R.S.V.P. to Bonnie Hiller (3-3051) or Hiller@Score by Friday, Jan. 13.
Since Monday 1/12 is a holiday, it might be harder to remember a 7:30 a.m.
appointment on Tuesday morning. We would like to have more CSD participation
in the Sunrise Club.
-------
∂10-Jan-89 0905 X3J13-mailer FTP access to compiler issues
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 10 Jan 89 09:05:26 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA03597; Tue, 10 Jan 89 10:04:18 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA11488; Tue, 10 Jan 89 10:04:15 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901101704.AA11488@defun.utah.edu>
Date: Tue, 10 Jan 89 10:04:14 MST
Subject: FTP access to compiler issues
To: x3j13@sail.stanford.edu
Copies of the pending issues from the compiler committee are available
for anonymous FTP from cs.utah.edu (128.110.4.21). Look in directory
pub/cl-compiler/pending.
There are also copies of the issues that were passed at the last meeting
in directory pub/cl-compiler/passed.
-Sandra
-------
∂10-Jan-89 0935 X3J13-mailer **DRAFT** issue COMPILED-FUNCTION-REQUIREMENTS, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 10 Jan 89 09:34:53 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA05135; Tue, 10 Jan 89 10:33:45 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA11507; Tue, 10 Jan 89 10:33:41 MST
Date: Tue, 10 Jan 89 10:33:41 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901101733.AA11507@defun.utah.edu>
To: x3j13@sail.stanford.edu
Subject: **DRAFT** issue COMPILED-FUNCTION-REQUIREMENTS, version 2
Reply-To: cl-compiler@sail.stanford.edu
Forum: Compiler
Issue: COMPILED-FUNCTION-REQUIREMENTS
References: CLtL p. 32, 76, 112, 143, 438-439
Issue FUNCTION-TYPE (passed)
Issue COMPILER-LET-CONFUSION
Issue EVAL-WHEN-NON-TOP-LEVEL
Issue LOAD-TIME-EVAL
Category: CLARIFICATION
Edit History: V1, 3 Jan 1989 Sandra Loosemore
V2, 10 Jan 1989, Sandra Loosemore (additional proposal)
Status: **DRAFT**
Problem Description:
There is confusion about what functions might be or must be of type
COMPILED-FUNCTION, and what attributes must be true of
COMPILED-FUNCTIONs. Is the distinction between COMPILED-FUNCTIONs and
other functions only one of representation, or can user programs infer
anything about COMPILED-FUNCTIONs? Are implementations required to
distinguish between compiled and non-compiled functions?
CLtL defines a COMPILED-FUNCTION as "a compiled code object". (Issue
FUNCTION-TYPE says only that COMPILED-FUNCTION must be a subtype of
FUNCTION.) Although it is not explicitly stated, CLtL implies that
compiled code must conform to certain rules; in particular, it states
that all macros are expanded at compile time, and specifies different
behavior for the COMPILER-LET and the EVAL-WHEN special forms
depending on whether they are interpreted or compiled.
The description of COMPILE in CLtL says that "a compiled-function object
[is] produced". It is not clear to everyone whether this implies that
COMPILED-FUNCTION-P must be true of such functions. CLtL says nothing
about whether functions defined in files compiled with COMPILE-FILE and
subsequently loaded must be of type COMPILED-FUNCTION.
Proposal COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN:
(1) Clarify that if a function is of type COMPILED-FUNCTION, the
following are guaranteed about the function:
- All macro calls within the function have already been expanded
and will not be expanded again when the function is called.
(See CLtL p. 143.)
- Nested COMPILER-LETs will not bind any variables when the function
is called (CLtL p. 112).
- If the function contains nested EVAL-WHENs, only the LOAD (and not
the EVAL) situation is applicable.
- If the function contains nested LOAD-TIME-VALUE forms, these have
already been pre-evaluated and will not be evaluated again when
the function is called.
(2) Implementations are free to classify all functions as
COMPILED-FUNCTIONs, provided that all functions satisfy the criteria
listed in item (1). It is also permissible for interpreted FUNCTIONs
to satisfy the above criteria but not be distinguished as
COMPILED-FUNCTIONs.
(3) Clarify that COMPILE always produces an object of type
COMPILED-FUNCTION. Clarify that when functions are defined in a
file which is compiled with COMPILE-FILE, and the compiled file is
subsequently LOADed, objects of type COMPILED-FUNCTION result.
Rationale:
This proposal assigns some specific properties to compiled functions.
It also states what many people believe to be the minimum functionality
required of a compiler.
Proposal COMPILED-FUNCTION-REQUIREMENTS:FLUSH:
(1) Remove the type specifier COMPILED-FUNCTION and the predicate
COMPILED-FUNCTION-P from the language.
(2) Clarify that functions produced by COMPILE, or defined in a file
that is compiled with COMPILE-FILE and then LOADed must satisfy
the same requirements listed in section (1) of the previous proposal.
Rationale:
Distinguishing between compiled and non-compiled functions is of
little use to portable programs.
This proposal states what many people believe to be the minimum
functionality required of a compiler.
Current Practice:
It appears that most implementations currently distinguish compiled
versus non-compiled functions on the basis of representation, but it
seems unlikely that any existing implementation would have problems
with the requirements in item (1).
A-Lisp uses the same representation for both compiled and interpreted
functions and currently labels them both as COMPILED-FUNCTION, but the
implementation of COMPILED-FUNCTION-P could be easily fixed to
distinguish "real" compiled functions.
On the TI Explorer, the COMPILE function can return an object of
either type COMPILED-FUNCTION or LEXICAL-CLOSURE, where the latter
consists of two components -- an environment and a COMPILED-FUNCTION.
There is confusion about whether microcoded functions should be
considered compiled or not.
Cost to implementors:
Unknown, but probably small for either proposal. Under proposal
FLUSH, implementations could continue to do whatever they do now with
the COMPILED-FUNCTION type as an extension.
Cost to users:
Probably minimal. Since the COMPILED-FUNCTION type specifier is
currently ill-defined, it is hard to imagine that existing programs
can portably rely on any interpretation of what it means that is
inconsistent with what is presented here.
Benefits:
The specification of what the compiler must do is made more explicit.
Discussion:
The FIXNUM and BIGNUM types were also defined in CLtL solely on the
basis of distinguished representations, and that this definition has
proved inadequate for just about all portable usages of these type
specifiers. Defining COMPILED-FUNCTION solely on the basis of
distinguished representation seems like a bad idea.
David Gray notes:
We make good use of the type COMPILED-FUNCTION in our implementation,
but all of the accessor functions for objects of that type are
non-standard, which makes me wonder if it might be best to just remove
this type from the standard along with BIGNUM.
One possible use of the COMPILED-FUNCTION type is in declarations. Are
there any implementations which have a distinguished representation for
COMPILED-FUNCTIONs, that use type declarations to compile calls to these
functions more efficiently?
∂10-Jan-89 1011 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu [jadams@note.nsf.gov: CISE Newsletter]
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Jan 89 10:11:52 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 10 Jan 89 10:09:08-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA10742; Tue, 10 Jan 89 10:07:11 PDT
Date: Tue, 10 Jan 89 10:07:11 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8901101807.AA10742@Tenaya.stanford.edu>
To: faculty@score
Subject: [jadams@note.nsf.gov: CISE Newsletter]
fyi:
Return-Path: <@Tenaya.stanford.edu,@Score.Stanford.EDU:jadams@note.nsf.gov>
To: cise.news@note.nsf.gov
Cc: wwulf@note.nsf.gov, cbrownst@note.nsf.gov, jdaen@note.nsf.gov,
bchern@note.nsf.gov, ytchien@note.nsf.gov, tweber@note.nsf.gov,
pfreeman@note.nsf.gov, swolff@note.nsf.gov, hhedges@note.nsf.gov,
bbarnes@note.nsf.gov, hgigley@note.nsf.gov, jlehmann@note.nsf.gov,
mciment@note.nsf.gov, dstaudt@note.nsf.gov, jadams@note.nsf.gov
Subject: CISE Newsletter
Date: Tue, 10 Jan 89 07:51:46 -0500
From: "J. Mack Adams" <jadams@note.nsf.gov>
NSF DIRECTORATE FOR
COMPUTER AND INFORMATION SCIENCE AND ENGINEERING (CISE)
NEWSLETTER
January 1989
This is the second CISE newsletter. For those who missed the
first, my intention is to help keep the "CISE community" aware of
developments in the Directorate -- the funding picture, new
initiatives, organizational and personnel changes, etc.
First some new items:
Science and Technology Centers
------------------------------
On Friday, December 2nd, the National Science Board approved 11
Science and Technology Centers, two of which fall into the areas
supported by CISE.
Rice University
Center for Research on Parallel Computation
This project is a multi-institutional, multi-state Center
involving researchers at Rice University, California Institute of
Technology, Argonne National Laboratory and Los Alamos National
Laboratory. The researchers will investigate parallel processing
at all levels including architecture, software and user
interfaces, algorithms and computational mathematics, as well as
applications in many significant areas. The Center Director will
be Ken Kennedy.
Rutgers University
Center for Discrete Mathematics and Theoretical Computer Science
Rutgers, in cooperation with Princeton University, AT&T Bell
Laboratories and Bell Communication Research, will establish a
Center wherein mathematicians and theoretical computer scientists
can share facilities to advance their own disciplines, but may
also ultimately contribute to progress in telecommunications,
transportation and computer design and manufacture. The Center
Director will be Daniel Gorenstein.
The Budget
----------
Since the last newsletter, the FY89 budget has become firm at
about $152 million (this includes 5.9 million for the two STC's),
up from $123 million in FY88. Of this, $84.4 million supports the
research activities of CISE, and is an increase of $11.2 million,
or 15.3%. $67.7 million supports the service activities of CISE (the
supercomputer centers and NSFNET), and is an increase of $17
million or 33.5%.
The large increase in the service component of CISE is related to
two things: (1) we will finally almost meet the cooperative
agreement levels at the supercomputer centers, and (2) NSFNET is
rapidly expanding as well as providing improved T1 (1.5 megabit)
service. The increase in the research budget, while certainly not
as large as we'd like it to be, was one of the highest percentage
increases in the Foundation.
Software Capitalization:
------------------------
CISE is concerned that academic researchers, especially in the
software research area, are under-capitalized -- NOT so much in
hardware, but by not having state-of-the-art software to support
their research and by not being able to build on software
produced on other research projects. To address this issue, I
have made available a modest amount of extra funds for use this
year in the various programs in CISE.
This money, to be matched by funds from the programs, is intended
to (1) fund purchase of off-the-shelf software packages, (2) help
support the distribution, maintenance, and evolution of software
that has resulted from prior research, and (3) provide for the
development of special-purpose software that will be of use to
one of our research communities. It is intended that NSF funds
will be augmented by industrial or university support and/or by
cost-of-distribution fees.
Details on proposals for software capitalization can be obtained
from the individual CISE program directors.
A few items from last time:
--------------------------
(1) NSF Staff Positions: If you or any of your colleagues are
interested in a temporary position, please contact me or my
staff. The following openings are anticipated:
Division Director for the Computer and Computation Division (CCR)
Program Directors in CCR for Computation Theory
and for Software Engineering
Program Director in OCDA for CISE Institutional Infrastructure
Program Directors in MIPS for Systems Architecture
and for Systems Prototyping & Fabrication
Program Director in ASC for Supercomputer Centers
(2) CISE Colloquium Series: If you would like to volunteer to
be a speaker in our 1989 fall colloquium series, please contact:
Y. T. Chien 202-357-9572 ytchien@note.nsf.gov
(3) Let me know if there are other things that you'd like to see
in this newsletter. I prefer to keep it short and informal, but
aside from that, anything's fair game. Distribution is primarily
by electronic mail, so if you get this by ordinary mail, please
send me your email address.
Bill Wulf
Assistant Director, CISE
wwulf@note.nsf.gov
202-357-7936
Editorial Note: After making a big deal out of doing this
electronically, I managed to foul up my email address,
so please note the correct address above. Also, if your
newsletter arrives in a garbled form due to the use of characters
that are incompatible with your host system, please let us know.
=================================================================
DIVISIONAL NEWS
Division of
Advanced Scientific Computing (ASC)
------------------------------------------------------------
Supercomputer Center News
Cornell Theory Center
A second IBM 3090/600VF was installed in early October 1988. This
six-processor supercomputer will be linked at high speed with
Cornell's first 3090/600 to experiment in clustering
supercomputers to provide 12-way parallelism.
John von Neumann Center
In late January 1989, the Center will install its second ETA10
liquid nitrogen cooled supercomputer, an eight processor machine
with 4 million words of local memory per processor, and a shared
memory of 256 million words. The new machine will join a similar
four processor ETA10 which has been available to researchers
since April 1988.
National Center for Supercomputing Applications - U. of Illinois
In November of 1988, NCSA installed its second CRAY
supercomputer, a Cray 2 with four processors and 128 million
words of main memory. This machine will complement the center's
first supercomputer, a Cray XMP48. Also, the center now has a
fifth industrial partner, FMC Corporation, bringing industrial
contributions at the centers to nearly $5M per year.
Pittsburgh Supercomputing Center
In early January 1989, PSC installed a new supercomputer, a Cray
YMP8/32. This is the first YMP delivered outside of a national
laboratory, and the first available to the general academic
community. It is expected to be 2-3 times as powerful as the Cray
XMP/48 which it replaces.
San Diego Supercomputer Center
The State of California has recently approved a grant of $2M
per year for three years to the SDSC to support the development
of an advanced computer graphics center. In combination with its
Cray XMP/48 supercomputer and SCS40 and Supertek mini-
supercomputers, the SDSC is expected to have one of the most
powerful and complete graphics facilities in the world.
------------------------------------------------------------
Personnel News
Dr. Thomas Weber has been appointed Division Director for the Division
of Advanced Scientific Computing. Dr. Weber came to DASC from the
the NSF Chemistry Division where he was Program Director for
Theoretical and Computational Chemistry. Dr. Weber previously was
a long term employee at the AT&T Bell Laboratories, where had strong
research interests in the use of advanced supercomputing.
Dr. Nathaniel Macon has been appointed Program Director for the New
Technologies Program. Dr. Macon came to DASC from the Division of
Computer and Computation Research where he served as Acting Program
Director for Software Engineering and Program Director for
Software Systems.
------------------------------------------------------------
ASC Advisory Panel Meeting Dates
April 1989 at NSF (exact dates not yet available)
===============================================================
Division of
Computer and Computation Research (CCR)
---------------------------------------------------------------
Annual Reports
Annual reports on CCR grants should be a simple statement of no
more than 10 pages, but may be much shorter. They should list
completing students (MS and PhD) including thesis titles and
current position (if known), citations (but not copies) of all
publications and tech reports, patents applied for,
undergraduates involved in project, talks given, and software
distributed; a one to two page narrative should be included that
describes the scientific progress made and the primary focus for
the coming year; especially noteworthy scientific achivements
should be separately described in a form that will facilitate NSF
using the information for internal purposes (i.e. a short
description). Requested budget changes should be clearly stated
and justified.
----------------------------------------------------------------
CCR Advisory Committee Meeting Dates
May 4 & 5, 1989
=================================================================
Division of
Information, Robotics and Intelligent Systems (IRIS)
----------------------------------------------------------------
IRIS Advisory Committee Meeting Dates
Spring, 1989 at NSF (exact dates to be determined)
=================================================================
Division of
Microelectronic Information Processing Systems (MIPS)
----------------------------------------------------------------
Personnel News
Alfred Susskind, Program Director for Systems Prototyping and
Fabrication, passed away last month. He will be sorely missed by
his colleagues within the Foundation and his associates outside
the Foundation.
Dr. P Ramamoorthy was appointed Program Director of the Circuits
and Signal Processing Program.
----------------------------------------------------------------
MIPS Advisory Committee Meeting Dates
January 30 and 31, 1989
=================================================================
Division of
Networking and Communications Research and Infrastructure (NCRI)
-----------------------------------------------------------
Program Announcement
Announcements for the Networking and Communications Research
Program are available. Deadlines for submission of proposals
are Dec. 1, 1988 and May 1, 1989. For announcements contact:
Darleen Fisher 202-357-9717 dfisher@note.nsf.gov
-----------------------------------------------------------
NCRI Advisory Panel Meeting Dates
Spring, 1989 (exact dates to be determined)
=================================================================
Office of
Cross-Disciplinary Activities (CDA)
-----------------------------------------------------------
Program Announcements
Announcements for the Institutional Infrastructure - Small
Scale (IISS) and Institutional Infrastructure - Minority
Institutions (IIMI) expansions of the regular Institutional
Infrastructure Program are available. Deadlines are
May 1, 1989 for the IISS, April 1, 1989 for the IIMI five
year awards, and February 1, 1989 for the IIMI one year
planning grants. For information contact:
J. Mack Adams 202-357-7349 jadams@note.nsf.gov
=================================================================
GENERAL ITEMS
-----------------------------------------------------------
Program Announcements
The new brochure for the 1989 Research Initiation Award program
is available. The guidelines are basically the same as for 1988
with the added provisions of only one proposal from an
investigator and only one investigator per proposal. The
deadline for submission of proposals is January 15, 1989.
The new announcement for the Instrumentation and Laboratory
Improvement Program is now available. For information contact
the Office of Undergraduate Science, Engineering, and
Mathematics Education, 202-357-7051.
---------------------------------------------------------------
REU
Research Experiences for Undergraduates (REU) Program awards
are made in two forms: autonomous awards (REU Sites) and
supplements to ongoing NSF research grants or contracts (REU
Supplements). Proposals for REU Sites are due no later than
October 10 annually, whereas proposals for REU Supplements will
be accepted at any time but should be submitted as early in the
fiscal year as possible. Inquiries about REU Sites may be
directed to CDA, 202-357-7349, and inquiries about REU
Supplements may be directed to the relevant NSF research program.
-----------------------------------------------------------------
Target Dates and Deadlines
In view of the many inquiries and frequent misunderstanding of
the terms "deadlines" and "target dates", an explanation may be
helpful. Deadlines are absolute, and proposals to programs with
deadlines must be in by the specified date or they will not be
considered. Target dates are guidelines and not absolute
requirements. For example, many programs will accept proposals
at any time, but suggest a target date near the beginning of the
fiscal year.
-----------------------------------------------------------------
Continuation Grants and Progress Reports
NSF has a new policy designed to reduce paperwork. The
Foundation will no longer require grantees to submit formal
requests and budgets to initiate continued support of grants
planned for incremental funding. Provided satisfactory
scientific progress is evidenced in the required annual progress
report and funds are available, NSF will award the annual
increment at the level indicated in the original grant letter
without a formal request. In order to obtain a committed funding
increment and ensure continuity of funding, the required progress
report must be forwarded to the cognizant program officer at
least 3 months prior to the expiration of the current support
period. NSF will require formal requests and budgets if specific
incremental amounts are not specified in the grant letter, or
where there are other special conditions in the grant. See NSF
Grant Policy Manual, Section 253 for details of the new policy.
-----------------------------------------------------------------
Educational Supplements to CISE Research Grants
We are planning an experimental program of Educational
Supplements to existing CISE research grants. Please be on the
look out for a dear colleague letter containing the details.
=================================================================
End of Newsletter
∂10-Jan-89 1104 SLOAN@Score.Stanford.EDU Fax Machine
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Jan 89 11:04:05 PST
Date: Tue 10 Jan 89 11:01:30-PST
From: Yvette Sloan <SLOAN@Score.Stanford.EDU>
Subject: Fax Machine
To: Faculty@Score.Stanford.EDU, Staff@Score.Stanford.EDU
Message-ID: <12461484987.25.SLOAN@Score.Stanford.EDU>
The Fax machine has been installed in the xerox room on the second floor.
The telephone number for the FAX line is (415) 725-7411.
The machine is operable, however, training on how to use it will not take
place until Thursday or Friday of this week. If you don't have experience
using one of these things, it might be best if you don't try sending anything
until some of us have had the proper training.
Happy faxing!
--Yvette
-------
∂10-Jan-89 1214 debra@russell.Stanford.EDU REMINDER
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Jan 89 12:14:50 PST
Received: from localhost by russell.Stanford.EDU (4.0/inc-1.0)
id AA09913; Tue, 10 Jan 89 12:16:24 PST
Message-Id: <8901102016.AA09913@russell.Stanford.EDU>
To: evesem@russell.Stanford.EDU
Cc: kuder@russell.Stanford.EDU, debra@russell.Stanford.EDU
Subject: REMINDER
Date: Tue, 10 Jan 89 12:16:22 PST
From: Debra Alty <debra@russell.Stanford.EDU>
REMINDER
The next EVENING SEMINAR will be Wednesday, January 11th @ 7:30pm in
the CSLI Cordura Conference Room.
Professor Jon Barwise, Philosphy Department, will be leading this
evening's discussion.
The following will be served:
Crab spread Cognac
Fruit Wine
Cheese Sparkling Waters
Crackers Coffee
Dessert Tea
Debra
∂10-Jan-89 1238 X3J13-mailer summary of open cl-compiler issues
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 10 Jan 89 12:38:10 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA13596; Tue, 10 Jan 89 13:36:57 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA11651; Tue, 10 Jan 89 13:36:53 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901102036.AA11651@defun.utah.edu>
Date: Tue, 10 Jan 89 13:36:50 MST
Subject: summary of open cl-compiler issues
To: x3j13@sail.stanford.edu
Here is a complete list of all open cl-compiler issues, as of today
(10 Jan 1989).
Non-draft issues distributed prior to January meeting:
ALLOW-LOCAL-INLINE (v4)
Interpretation of INLINE/NOTINLINE declarations.
COMPILE-ENVIRONMENT-CONSISTENCY (v3)
What kinds of things can/must the compiler "wire in" to the code
it compiles?
DEFCONSTANT-SPECIAL (v3)
Does DEFCONSTANT proclaim the variable SPECIAL?
LOAD-TIME-EVAL (v8)
Add a new special form similar to what #, does.
SHARP-COMMA-CONFUSION (v2)
Remove the #, read macro.
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS (v8)
Clarify compile-time side effects of various defining macros.
CONSTANT-MODIFICATION (v2)
It's an error to destructively modify quoted constants.
Draft issues distributed prior to January meeting:
COMPILER-DIAGNOSTICS (v8)
Clarify status and handling of errors and warnings signalled during
compilation.
COMPILER-VERBOSITY (v5)
Mechanisms for controlling progress messages issued by the compiler.
CONSTANT-COMPILABLE-TYPES (v5)
What types of objects can appear as quoted or self-evaluating constants
in compiled code?
CONSTANT-CIRCULAR-COMPILATION (v5)
Must circular or recursive objects be compiled correctly? Must the
compiler preserve sharing of substructures?
CONSTANT-COLLAPSING (v5)
Should the compiler be allowed to "collapse" or coalesce constants
that satisfy a more general equivalence relationship than EQUAL?
QUOTE-MAY-COPY (v4)
May COMPILE and EVAL construct equivalent copies of quoted or
self-evaluating constants, or must constants share structure with
the source code for the program? Do the constraints on what objects
are valid constants also apply to COMPILE and EVAL, or only to
COMPILE-FILE?
EVAL-WHEN-NON-TOP-LEVEL (v4)
What does EVAL-WHEN mean when it appears in non-top-level locations?
DEFINING-MACROS-NON-TOP-LEVEL (v7)
Are defining macros such as DEFUN meaningful in non-top-level locations?
COMPILED-FUNCTION-REQUIREMENTS (v2)
What does the COMPILED-FUNCTION type imply? Do COMPILE and
COMPILE-FILE construct COMPILED-FUNCTIONs?
Other issues under discussion but not yet distributed:
COMPILER-LET-CONFUSION (v5)
The description of COMPILER-LET in CLtL is broken -- should we fix
it or eliminate it entirely?
MACRO-ENVIRONMENT-EXTENT (v1)
Do environment objects received as the &ENVIRONMENT argument to a
macro have dynamic or indefinite extent?
MACRO-ENVIRONMENT-CREATOR (v1)
How can code-walkers add the macro definitions in a MACROLET to
an environment object suitable for passing to MACROEXPAND?
DEFCONSTANT-NOT-WIRED (v5)
Add a way to declare a constant like DEFCONSTANT, but without giving
the compiler permission to "wire in" the value into compiled code.
Issues where proposals have been submitted but not followed up on:
CONSTANT-ARRAY-ATTRIBUTES
What attributes of constant arrays are preserved by compilation?
Probably subsumed by CONSTANT-COMPILABLE-TYPES.
COMPILE-FILE-ENVIRONMENT
Clarify that macro environment objects contain information about
whether it was built by the compiler or interpreter.
Superseded by issue SYNTACTIC-ENVIRONMENT-ACCESS, unless that issue
has died.
DEFCONSTANT-VALUE
When is the value form to DEFCONSTANT evaluated?
Subsumed by issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS.
DEFINE-OPTIMIZER
Provide a macro-like way of specifying source-to-source transformations.
Waiting for revisions (Pitman)
FILE-COMPILATION
same issue as CONSTANT-COMPILABLE-TYPES?
PROCLAIM-ETC-IN-COMPILE-FILE
Are top-level calls to PROCLAIM handled specially by the compiler?
Waiting for resolution of related cleanup issues (DEFPACKAGE,
IN-PACKAGE-FUNCTIONALITY)
SYNTACTIC-ENVIRONMENT-ACCESS
Provide accessors and constructors for lexical environment objects.
Waiting for new writeup (Benson)
WITH-COMPILATION-UNIT
Provide a way to compile a group of files as a unit for the purposes
of error messages.
Waiting for revisions to existing proposal (Pitman)
-------
∂10-Jan-89 1307 barwise@russell.Stanford.EDU Interns
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Jan 89 13:07:30 PST
Received: from localhost by russell.Stanford.EDU (4.0/inc-1.0)
id AA10232; Tue, 10 Jan 89 13:06:57 PST
Message-Id: <8901102106.AA10232@russell.Stanford.EDU>
To: ssp-faculty@russell.Stanford.EDU
Subject: Interns
Date: Tue, 10 Jan 89 13:06:54 PST
From: Jon Barwise <barwise@russell.Stanford.EDU>
Dear Faculty,
Below is an announcement of the SSP Summer Intern program sponsored in
part by CSLI. This year CSLI is providing matching funds (rather than
full funds) to support student researchers on ssp faculty projects.
There will be at most six internships. You will note that the
students are paid 10.15/ hour for 40 hours a week, for 10 weeks, plus
fringe benefits. (I guess I should find out that 1/2 of that total
comes to.)
We are also asking faculty to send Helen short descriptions of research
projects that might fit under this Internship program. We will be
making the formal announcement of the program at the SSP Forum on
the 20th, so please get them in before then. Last summer's program was
such a success, that I expect a lot of student interest this year.
If you have any questions, send Helen or me a message.
Jon
---------
CSLI Summer Internships for SSP Majors
The Center for the Study of Language and Information at Stanford is
pleased to announce its second Summer Internship Program for the
students and faculty of the Symbolic Systems Program. The goal of the
internship program is to promote in students a richer understanding of
the shared interdisciplinary field of the Symbolic Systems Program and
CSLI by supporting student participation in ongoing research projects
in this field.
Description: Student interns work with SSP faculty members assisting
on a research project. Internships are full-time (40 hours a week at
$10.25/ hour) and extend over the ten week period period July 3 -
September 8, 1989. These funds come jointly from CSLI and research
funds of the projects in question. Successful completion of the
internship requires a short written report on the work completed by
the intern or a presentation of the work to the SSP Forum.
Application Materials to include the following: (1) A brief
description of the general research project that the student wishes to
join, including details of the student's proposed role in the project.
(2) A letter of agreement from the proposed faculty supervisor, which
approves the student proposal. (3) A letter of recommendation from a
faculty member who has taught an SSP course completed by the
applicant. (This may be the same letter as in 2, but need not be.)
(4) A copy of student's transcript.
Application Deadline: April 7, 1989
The Symbolic Systems Program office has a list of research projects
and faculty advisors available this summer. Applications to be
submitted to: Symbolic Systems Program, 60:62H, Stanford University,
Stanford CA 94305-2181. For more information contact the program
office at: 723-4091.
∂10-Jan-89 1350 @Score.Stanford.EDU:ungar@self Re: Reminder of Sunrise Club breakfast on Tuesday, 1/17
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Jan 89 13:49:59 PST
Received: from self by SCORE.STANFORD.EDU with TCP; Tue 10 Jan 89 13:44:51-PST
Received: by self (4.0/inc-1.0)
id AA03125; Tue, 10 Jan 89 13:43:13 PST
Date: Tue, 10 Jan 89 13:43:13 PST
From: ungar@self.stanford.edu (David Ungar)
Message-Id: <8901102143.AA03125@self>
To: TAJNAI@Score.Stanford.EDU, faculty@Score.Stanford.EDU,
phd@Score.Stanford.EDU, ras@Score.Stanford.EDU
Subject: Re: Reminder of Sunrise Club breakfast on Tuesday, 1/17
One way to increase participation might be change the meeting time.
David
∂10-Jan-89 1543 X3J13-mailer Issue: APPLYHOOK-ENVIRONMENT (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jan 89 15:43:41 PST
Received: from Semillon.ms by ArpaGateway.ms ; 10 JAN 89 15:42:31 PST
Date: 10 Jan 89 15:42 PST
From: masinter.pa@Xerox.COM
Subject: Issue: APPLYHOOK-ENVIRONMENT (Version 2)
To: x3j13@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
line-fold: no
cc: masinter.pa@Xerox.COM
Message-ID: <890110-154231-6930@Xerox>
In addition to the many issues on the ballot, there are
a number of other issues that are in various states of
completion. If we have time, we may be able to consider
some of these.
!
Forum: Cleanup
Issue: APPLYHOOK-ENVIRONMENT
References: APPLYHOOK (CLtL p. 323)
Category: CHANGE
Edit history: Masinter, 6-Jan-89, Version 1
Masinter, 10-Jan-89, Version 2
Problem description:
The function APPLYHOOK is documented to take an optional environment
argument. CLtL says "Furthermore, the env argument is used as the lexical
environment for the operation; env defaults to the null environment."
However, there is no way that the lexical environment can effect the way in
which APPLYHOOK processes its arguments; it merely calls the specified
function, and function call is not affected by lexical environments. (The
"function" argument to APPLYHOOK is a function object.)
This has been regularly a source of confusion for programmers encountering
APPLYHOOK.
The comments also apply to functions bound to *APPLYHOOK*, i.e., under the
description of *APPLYHOOK* on p.322, the following
"The non-NIL value of *APPLYHOOK* should be a function that takes
three arguments, a function, a list of arguments and an
environment..."
Proposal (APPLYHOOK-ENVIRONMENT:REMOVE-ENV):
Remove the optional "ENV" argument to APPLYHOOK. Specify
that the non-NIL value of *APPLYHOOK* should be a function that takes
two arguments, a function and a list of arguments.
Rationale:
Removes a very minor wart.
Current practice:
Most implementations accept an extra argument and then ignore it.
Cost to Implementors:
Remove optional ENV argument from APPLYHOOK and any code that passes one to
APPLYHOOK.
Cost to Users:
Remove any ENV argument passed to APPLYHOOK. Fix any *APPLYHOOK*
functions to only take two arguments (or to make the third argument optional.)
Cost of non-adoption:
Continued confusion.
Performance impact:
None
Benefits:
Removes a wart.
Esthetics:
Minor improvement.
Discussion:
This was discussed on the Common Lisp mailing list several years ago, but
slipped through the cracks.
∂10-Jan-89 1555 X3J13-mailer Issue: COMPLEX-ATAN-BRANCH-CUT, (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jan 89 15:55:49 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JAN 89 15:53:55 PST
Date: 10 Jan 89 15:53 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: COMPLEX-ATAN-BRANCH-CUT, (Version 1)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890110-155355-6963@Xerox>
!
Forum: Cleanup
Issue: COMPLEX-ATAN-BRANCH-CUT
References: CLtL p.208, 212
Related issues: IEEE-ATAN-BRANCH-CUT
Category: CHANGE
Edit history: Version 1, 13-Dec-88, Steele
Problem description:
The formula that defines ATAN results in a branch cut that is at
variance with the recommendations of Prof. W. Kahan and with the
implementations of that function in many computing systems and
calculators.
Proposal (COMPLEX-ATAN-BRANCH-CUT:TWEAK):
Replace the formula
arctan z = - i log ((1+iz) sqrt (1/(1+z↑2)))
with the formula
arctan z = (log (1+iz) - log (1-iz)) / (2i)
This leaves the branch cuts pretty much in place; the only change is
that the upper branch cut (on the positive imaginary axis above i)
is continuous with quadrant I, where the old formula has it continuous
with quadrant II.
Examples:
(atan #c(0 2)) => #c(-1.57... 0.549...) ;Current
(atan #c(0 2)) => #c(1.57... -0.549...) ;Proposed
Note: 1.57... = pi/2, and 0.549... = (log 3)/2.
Rationale:
Compatibility with what seems to be becoming standard practice.
Current practice:
(atan #c(0 2)) => #c(-1.57... 0.549...) ;Symbolics CL
(atan #c(0 2)) => #c(-1.57... 0.549...) ;Allegro CL 1.1 (Macintosh)
(atan #c(0 2)) => #c(-1.57... 0.549...) ;Sun-4 CL 2.1.3 of 10-Nov-88
(atan #c(0 2)) => #c(1.57... -0.549...) ;Sun CL 2.0.3 of 30-Jun-87
(atan #c(0 2)) => #c(1.57... 0.549...) ;KCL of 3-Jun-87
Note that in KCL the upper branch cut is thus continuous with
quadrant I, but its lower branch cut is continuous with quadrant III!
Cost to Implementors:
ATAN must be rewritten. It is not a very difficult fix.
Cost to Users:
It is barely conceivable that some user code could depend on this.
Note that the proposed change invalidates the identities
arctan i z = i arctanh z
and arctanh i z = i arctan z
on the upper branch cut.
The compatibility note on p. 210 of CLtL gave users fair warning that
a change of this kind might be adopted.
Cost of non-adoption:
Incompatibility with HP calculators.
Benefits:
Numerical analystsmay find the new definition easier to use.
Esthetics:
A toss-up, except to those who care.
Discussion:
Steele has sent a letter to W. Kahan at Berkeley to get any last
comments he may have on the matter.
Paul Penfield of MIT, after whose article the Common Lisp branch
cuts were originally patterned, endorses this change.
∂10-Jan-89 1710 X3J13-mailer Issue: DEFSTRUCT-ACCESS-FUNCTIONS-INLINE, (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jan 89 17:09:52 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JAN 89 17:08:39 PST
Date: 10 Jan 89 17:08 PST
Sender: masinter.pa@Xerox.COM
Forum: Cleanup
Subject: Issue: DEFSTRUCT-ACCESS-FUNCTIONS-INLINE, (Version 2)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890110-170839-7158@Xerox>
!
Issue: DEFSTRUCT-ACCESS-FUNCTIONS-INLINE
References: DEFSTRUCT (p. 308)
Category: CHANGE
Edit history: 5-Oct-88, Version 1 by Chapman
6-Jan-89, Version 2 by Masinter
Problem Description:
It is left up to the implementation whether or not the DEFSTRUCT access
function is declared inline. Thus, some programmers write:
(PROCLAIM '(INLINE FOO-A FOO-B FOO-C))
(DEFSTRUCT FOO A B C)
in portable code in case the code is run in an implementation where
the INLINE proclaimation is meaningful but not the default for
DEFSTRUCT accessors.
Proposal (DEFSTRUCT-ACCESS-FUNCTIONS-INLINE:YES)
Make it mandatory that implementations declare access functions inline.
Of course the declaration may or may not mean anything within the
particular implementation.
Rationale:
This requirement resolves user ambiguity.
Current Practice:
We've not surveyed many implementations, but apparently they
differ as to whether INLINE for defstruct accessors is the default.
Cost to implementors:
Minimal.
Cost to users:
Minimal.
Benefits:
This clarification will give users insurance that the inline declaration
has been made for the access function.
Aesthetics:
Specified is simpler than not-specified.
Performance Impact:
Small. Some programs might have different size/space characteristics.
Discussion:
We know of no implementation where such automatic inlining would
be inappropriate, even in cases where INLINE is recognized. Certainly
implementations are free to ignore INLINE proclaimations even
selectively, i.e., ignore INLINE proclaimations only for DEFSTRUCT
accessors. The major impact of this proposal is just to make it clear
that a separate (PROCLAIM '(INLINE ...)) is not necessary.
∂10-Jan-89 1836 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu [jadams@note.nsf.gov: CISE Newsletter]
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Jan 89 18:36:27 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 10 Jan 89 18:33:25-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA10742; Tue, 10 Jan 89 10:07:11 PDT
Date: Tue, 10 Jan 89 10:07:11 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8901101807.AA10742@Tenaya.stanford.edu>
To: faculty@score
Subject: [jadams@note.nsf.gov: CISE Newsletter]
fyi:
Return-Path: <@Tenaya.stanford.edu,@Score.Stanford.EDU:jadams@note.nsf.gov>
To: cise.news@note.nsf.gov
Cc: wwulf@note.nsf.gov, cbrownst@note.nsf.gov, jdaen@note.nsf.gov,
bchern@note.nsf.gov, ytchien@note.nsf.gov, tweber@note.nsf.gov,
pfreeman@note.nsf.gov, swolff@note.nsf.gov, hhedges@note.nsf.gov,
bbarnes@note.nsf.gov, hgigley@note.nsf.gov, jlehmann@note.nsf.gov,
mciment@note.nsf.gov, dstaudt@note.nsf.gov, jadams@note.nsf.gov
Subject: CISE Newsletter
Date: Tue, 10 Jan 89 07:51:46 -0500
From: "J. Mack Adams" <jadams@note.nsf.gov>
NSF DIRECTORATE FOR
COMPUTER AND INFORMATION SCIENCE AND ENGINEERING (CISE)
NEWSLETTER
January 1989
This is the second CISE newsletter. For those who missed the
first, my intention is to help keep the "CISE community" aware of
developments in the Directorate -- the funding picture, new
initiatives, organizational and personnel changes, etc.
First some new items:
Science and Technology Centers
------------------------------
On Friday, December 2nd, the National Science Board approved 11
Science and Technology Centers, two of which fall into the areas
supported by CISE.
Rice University
Center for Research on Parallel Computation
This project is a multi-institutional, multi-state Center
involving researchers at Rice University, California Institute of
Technology, Argonne National Laboratory and Los Alamos National
Laboratory. The researchers will investigate parallel processing
at all levels including architecture, software and user
interfaces, algorithms and computational mathematics, as well as
applications in many significant areas. The Center Director will
be Ken Kennedy.
Rutgers University
Center for Discrete Mathematics and Theoretical Computer Science
Rutgers, in cooperation with Princeton University, AT&T Bell
Laboratories and Bell Communication Research, will establish a
Center wherein mathematicians and theoretical computer scientists
can share facilities to advance their own disciplines, but may
also ultimately contribute to progress in telecommunications,
transportation and computer design and manufacture. The Center
Director will be Daniel Gorenstein.
The Budget
----------
Since the last newsletter, the FY89 budget has become firm at
about $152 million (this includes 5.9 million for the two STC's),
up from $123 million in FY88. Of this, $84.4 million supports the
research activities of CISE, and is an increase of $11.2 million,
or 15.3%. $67.7 million supports the service activities of CISE (the
supercomputer centers and NSFNET), and is an increase of $17
million or 33.5%.
The large increase in the service component of CISE is related to
two things: (1) we will finally almost meet the cooperative
agreement levels at the supercomputer centers, and (2) NSFNET is
rapidly expanding as well as providing improved T1 (1.5 megabit)
service. The increase in the research budget, while certainly not
as large as we'd like it to be, was one of the highest percentage
increases in the Foundation.
Software Capitalization:
------------------------
CISE is concerned that academic researchers, especially in the
software research area, are under-capitalized -- NOT so much in
hardware, but by not having state-of-the-art software to support
their research and by not being able to build on software
produced on other research projects. To address this issue, I
have made available a modest amount of extra funds for use this
year in the various programs in CISE.
This money, to be matched by funds from the programs, is intended
to (1) fund purchase of off-the-shelf software packages, (2) help
support the distribution, maintenance, and evolution of software
that has resulted from prior research, and (3) provide for the
development of special-purpose software that will be of use to
one of our research communities. It is intended that NSF funds
will be augmented by industrial or university support and/or by
cost-of-distribution fees.
Details on proposals for software capitalization can be obtained
from the individual CISE program directors.
A few items from last time:
--------------------------
(1) NSF Staff Positions: If you or any of your colleagues are
interested in a temporary position, please contact me or my
staff. The following openings are anticipated:
Division Director for the Computer and Computation Division (CCR)
Program Directors in CCR for Computation Theory
and for Software Engineering
Program Director in OCDA for CISE Institutional Infrastructure
Program Directors in MIPS for Systems Architecture
and for Systems Prototyping & Fabrication
Program Director in ASC for Supercomputer Centers
(2) CISE Colloquium Series: If you would like to volunteer to
be a speaker in our 1989 fall colloquium series, please contact:
Y. T. Chien 202-357-9572 ytchien@note.nsf.gov
(3) Let me know if there are other things that you'd like to see
in this newsletter. I prefer to keep it short and informal, but
aside from that, anything's fair game. Distribution is primarily
by electronic mail, so if you get this by ordinary mail, please
send me your email address.
Bill Wulf
Assistant Director, CISE
wwulf@note.nsf.gov
202-357-7936
Editorial Note: After making a big deal out of doing this
electronically, I managed to foul up my email address,
so please note the correct address above. Also, if your
newsletter arrives in a garbled form due to the use of characters
that are incompatible with your host system, please let us know.
=================================================================
DIVISIONAL NEWS
Division of
Advanced Scientific Computing (ASC)
------------------------------------------------------------
Supercomputer Center News
Cornell Theory Center
A second IBM 3090/600VF was installed in early October 1988. This
six-processor supercomputer will be linked at high speed with
Cornell's first 3090/600 to experiment in clustering
supercomputers to provide 12-way parallelism.
John von Neumann Center
In late January 1989, the Center will install its second ETA10
liquid nitrogen cooled supercomputer, an eight processor machine
with 4 million words of local memory per processor, and a shared
memory of 256 million words. The new machine will join a similar
four processor ETA10 which has been available to researchers
since April 1988.
National Center for Supercomputing Applications - U. of Illinois
In November of 1988, NCSA installed its second CRAY
supercomputer, a Cray 2 with four processors and 128 million
words of main memory. This machine will complement the center's
first supercomputer, a Cray XMP48. Also, the center now has a
fifth industrial partner, FMC Corporation, bringing industrial
contributions at the centers to nearly $5M per year.
Pittsburgh Supercomputing Center
In early January 1989, PSC installed a new supercomputer, a Cray
YMP8/32. This is the first YMP delivered outside of a national
laboratory, and the first available to the general academic
community. It is expected to be 2-3 times as powerful as the Cray
XMP/48 which it replaces.
San Diego Supercomputer Center
The State of California has recently approved a grant of $2M
per year for three years to the SDSC to support the development
of an advanced computer graphics center. In combination with its
Cray XMP/48 supercomputer and SCS40 and Supertek mini-
supercomputers, the SDSC is expected to have one of the most
powerful and complete graphics facilities in the world.
------------------------------------------------------------
Personnel News
Dr. Thomas Weber has been appointed Division Director for the Division
of Advanced Scientific Computing. Dr. Weber came to DASC from the
the NSF Chemistry Division where he was Program Director for
Theoretical and Computational Chemistry. Dr. Weber previously was
a long term employee at the AT&T Bell Laboratories, where had strong
research interests in the use of advanced supercomputing.
Dr. Nathaniel Macon has been appointed Program Director for the New
Technologies Program. Dr. Macon came to DASC from the Division of
Computer and Computation Research where he served as Acting Program
Director for Software Engineering and Program Director for
Software Systems.
------------------------------------------------------------
ASC Advisory Panel Meeting Dates
April 1989 at NSF (exact dates not yet available)
===============================================================
Division of
Computer and Computation Research (CCR)
---------------------------------------------------------------
Annual Reports
Annual reports on CCR grants should be a simple statement of no
more than 10 pages, but may be much shorter. They should list
completing students (MS and PhD) including thesis titles and
current position (if known), citations (but not copies) of all
publications and tech reports, patents applied for,
undergraduates involved in project, talks given, and software
distributed; a one to two page narrative should be included that
describes the scientific progress made and the primary focus for
the coming year; especially noteworthy scientific achivements
should be separately described in a form that will facilitate NSF
using the information for internal purposes (i.e. a short
description). Requested budget changes should be clearly stated
and justified.
----------------------------------------------------------------
CCR Advisory Committee Meeting Dates
May 4 & 5, 1989
=================================================================
Division of
Information, Robotics and Intelligent Systems (IRIS)
----------------------------------------------------------------
IRIS Advisory Committee Meeting Dates
Spring, 1989 at NSF (exact dates to be determined)
=================================================================
Division of
Microelectronic Information Processing Systems (MIPS)
----------------------------------------------------------------
Personnel News
Alfred Susskind, Program Director for Systems Prototyping and
Fabrication, passed away last month. He will be sorely missed by
his colleagues within the Foundation and his associates outside
the Foundation.
Dr. P Ramamoorthy was appointed Program Director of the Circuits
and Signal Processing Program.
----------------------------------------------------------------
MIPS Advisory Committee Meeting Dates
January 30 and 31, 1989
=================================================================
Division of
Networking and Communications Research and Infrastructure (NCRI)
-----------------------------------------------------------
Program Announcement
Announcements for the Networking and Communications Research
Program are available. Deadlines for submission of proposals
are Dec. 1, 1988 and May 1, 1989. For announcements contact:
Darleen Fisher 202-357-9717 dfisher@note.nsf.gov
-----------------------------------------------------------
NCRI Advisory Panel Meeting Dates
Spring, 1989 (exact dates to be determined)
=================================================================
Office of
Cross-Disciplinary Activities (CDA)
-----------------------------------------------------------
Program Announcements
Announcements for the Institutional Infrastructure - Small
Scale (IISS) and Institutional Infrastructure - Minority
Institutions (IIMI) expansions of the regular Institutional
Infrastructure Program are available. Deadlines are
May 1, 1989 for the IISS, April 1, 1989 for the IIMI five
year awards, and February 1, 1989 for the IIMI one year
planning grants. For information contact:
J. Mack Adams 202-357-7349 jadams@note.nsf.gov
=================================================================
GENERAL ITEMS
-----------------------------------------------------------
Program Announcements
The new brochure for the 1989 Research Initiation Award program
is available. The guidelines are basically the same as for 1988
with the added provisions of only one proposal from an
investigator and only one investigator per proposal. The
deadline for submission of proposals is January 15, 1989.
The new announcement for the Instrumentation and Laboratory
Improvement Program is now available. For information contact
the Office of Undergraduate Science, Engineering, and
Mathematics Education, 202-357-7051.
---------------------------------------------------------------
REU
Research Experiences for Undergraduates (REU) Program awards
are made in two forms: autonomous awards (REU Sites) and
supplements to ongoing NSF research grants or contracts (REU
Supplements). Proposals for REU Sites are due no later than
October 10 annually, whereas proposals for REU Supplements will
be accepted at any time but should be submitted as early in the
fiscal year as possible. Inquiries about REU Sites may be
directed to CDA, 202-357-7349, and inquiries about REU
Supplements may be directed to the relevant NSF research program.
-----------------------------------------------------------------
Target Dates and Deadlines
In view of the many inquiries and frequent misunderstanding of
the terms "deadlines" and "target dates", an explanation may be
helpful. Deadlines are absolute, and proposals to programs with
deadlines must be in by the specified date or they will not be
considered. Target dates are guidelines and not absolute
requirements. For example, many programs will accept proposals
at any time, but suggest a target date near the beginning of the
fiscal year.
-----------------------------------------------------------------
Continuation Grants and Progress Reports
NSF has a new policy designed to reduce paperwork. The
Foundation will no longer require grantees to submit formal
requests and budgets to initiate continued support of grants
planned for incremental funding. Provided satisfactory
scientific progress is evidenced in the required annual progress
report and funds are available, NSF will award the annual
increment at the level indicated in the original grant letter
without a formal request. In order to obtain a committed funding
increment and ensure continuity of funding, the required progress
report must be forwarded to the cognizant program officer at
least 3 months prior to the expiration of the current support
period. NSF will require formal requests and budgets if specific
incremental amounts are not specified in the grant letter, or
where there are other special conditions in the grant. See NSF
Grant Policy Manual, Section 253 for details of the new policy.
-----------------------------------------------------------------
Educational Supplements to CISE Research Grants
We are planning an experimental program of Educational
Supplements to existing CISE research grants. Please be on the
look out for a dear colleague letter containing the details.
=================================================================
End of Newsletter
∂10-Jan-89 2258 @Score.Stanford.EDU:cheriton@Pescadero.Stanford.EDU Re: [jadams@note.nsf.gov: CISE Newsletter]
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Jan 89 22:58:08 PST
Received: from Pescadero.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 10 Jan 89 22:54:58-PST
Received: by Pescadero.Stanford.EDU (5.59/25-eef) id AA02827; Tue, 10 Jan 89 22:57:49 PDT
Date: Tue, 10 Jan 89 22:57:49 PDT
From: David Cheriton <cheriton@Pescadero.Stanford.EDU>
Message-Id: <8901110657.AA02827@Pescadero.Stanford.EDU>
To: faculty@score, nilsson@Tenaya.stanford.edu
Subject: Re: [jadams@note.nsf.gov: CISE Newsletter]
In-Reply-To: <8901101807.AA10742@Tenaya.stanford.edu> from Nils Nilsson
<nilsson@Tenaya.stanford.edu> on Tue, 10 Jan 89 10:07:11 PDT
The NSF newsletter reads like a victory statement from the physicists.
They have clearly reduced CS to a marketing ploy to drain increasing
amounts of the country's resources into chasing particules of their
imagination which dont even exist with less than 5 levels of subscripts.
The popular opinion seems to be that the military detracts from our
commercial competitiveness, yet even in my narrow little universe
I see it has funded the research that lead to Sun, Silicon Graphics,
MIPS, Protean, etc., etc. I'll shutup when I see something coming out
of these "supercomputer" centers, supercolider other than the discovery
that there must be more useless particles that will cost us even more to find.
I'm sure that the Japanse are very thankful that we are willing to strangel
the applied research in this country to provide them with basic science
so they can concentrate their resources on completely dominating us in
all the major technologies that have any foreseeable payoff.
(flame-off)
∂10-Jan-89 2349 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Urgent: announcement of panel on funding
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Jan 89 23:49:14 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA15190; Tue, 10 Jan 89 23:48:11 PDT
Message-Id: <8901110748.AA15190@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 10 Jan 89 23:48:15 PST
Received: by BYUADMIN (Mailer R2.01A) id 4000; Wed, 11 Jan 89 00:45:02 MST
Date: Tue, 10 Jan 89 15:47:40 PST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
simons@IBM.COM
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
From: "Barbara B. Simons" <simons@IBM.COM>
Subject: Urgent: announcement of panel on funding
Comments: To: theorynt@vm1.nodak.edu
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
FEDERAL FUNDING OF THE ACADEMIC PHYSICAL SCIENCES
PANELISTS
Prof. Philip Anderson (Nobel Prize)
Physics, Princeton University
Prof. Richard Karp (Turing Award)
Computer science, U.C. Berkeley
Prof. Robert Park
Executive Director, Office of Public Affairs, The American Physical Society
Dr. Burton Richter (Nobel Prize)
Director, SLAC
Dr. Robert M. Rosenzweig
President, Association of American Universities
Prof. William Thurston (Fields Medal)
Mathematics, Princeton University
Moderator: Dr. Barbara Simons
Computer Science, IBM Almaden Research Center
Abstract: Federal funding of science is a major component of science policy.
Which areas are funded, how much funding they receive, which agencies do the
funding, and who makes the decisions are important issues. Fields prosper and
decline according to these decisions. Graduate students' choice of specialty
is influenced by funding. Teaching loads and even tenure decisions can be
affected. Since funding has a profound influence on technology, funding
policy has significant economic repercussions. It also has political
repercussions, as politicians become increasingly involved with the funding
process. Scientific and academic freedom are at issue. Researchers who fear
that their funding may be cut for political reasons, even if the fears are
unfounded, may engage in self-censorship.
What should be national funding priorities?
What has been the effect of the increased emphasis on 'big science' in recent
years?
How have the trends toward mission oriented and defense oriented funding
affected the quality and nature of scientific research?
Is there an imbalance of funding sources for some scientific disciplines, and,
if so, is this a problem?
What impact has science funding policy had on universities, faculty, and
graduate students?
Have government policies with respect to science funding been in the best
interest of science?
Are there ways in which these policies can be improved?
Date: Tuesday Jan. 17, 1989
Time: 8:30 A.M. - 11:30 A.M.
Place: the California East Room of the St. Francis Hotel, San Francisco
Sponsored by: the American Association for the Advancement of Science, the
American Physical Society, and the American Association of Physics Teachers
The panel is a part of several parallel conferences, namely the AAAS, the APS,
and the AAPT. I don't know whether or not one can walk in without having
registered at one of these conferences. It is possible to register at the APS
conference for a single day for $50. There is a student registration fee for
the entire AAAS conference of $50 or $70, for members and non-members
respectively.
∂11-Jan-89 1429 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Jan 89 12:21:55 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Wed 11 Jan 89 12:04:41-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA00245; Wed, 11 Jan 89 12:04:44 PDT
Date: Wed, 11 Jan 89 12:04:44 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8901112004.AA00245@Tenaya.stanford.edu>
To: phd-prcom@score
Cc: faculty@score
I am encouraged by the discussions and thought now going in to
our PhD program. I believe the step taken by the faculty yesterday,
namely replacing Grey Tuesday by quarterly meetings, deals very well
with the fact that we simply don't have time to consider all of the
students at the Grey Tuesday meetings. My sense is that this change
is non-controversial.
I expect that additional suggestions for changes in the PhD program
will have many pros and cons. As a Department we must make any changes
very carefully---listening to all concerned constituencies. I suggest
the following procedure:
1) Faculty lunch discussion of some of the different points of
view about the PhD program. We are going to be having such a discussion
at our faculty lunch of Jan. 24.
2) Detailed and thorough consideration of various options by the
PhD program committee. During this time, I expect that the program
committee will be keeping the rest of the faculty informed about their
thoughts and will be receiving feedback from the faculty.
3) Preparation by the PhD program committee of a recommendation or
a set of alternative recommendations to be presented to the faculty.
These should be set forth rather formally. If there are differences
of opinion in the committee, then there should be a majority and
a minority report to the faculty. I believe we are dealing with
matters too important to hurry. In particular, I do not think that
the committee report should be prepared hurriedly nor should votes be
taken among the committee members by e-mail (especially, we should not
have a situation in which the committee report is finalized by
any kind of if-I-hear-no-objections-to-the-following-proposal action).
The faculty and future generations of PhD students deserve a more formal
process in this case I think.
4) Final discussions of the formal committee report by the faculty
in a scheduled meeting and a decision by the faculty.
I would rather have us do this right (slowly and carefully) than have
us have to do it over again next year!
-Nils
∂11-Jan-89 1433 X3J13-mailer Another DRAFT Agenda
Received: from lucid.com ([192.26.25.1]) by SAIL.Stanford.EDU with TCP; 11 Jan 89 12:33:01 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA03447g; Wed, 11 Jan 89 08:58:23 PST
Received: by challenger id AA02160g; Wed, 11 Jan 89 08:54:16 PST
Date: Wed, 11 Jan 89 08:54:16 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8901111654.AA02160@challenger>
To: x3j13@sail.stanford.edu
Subject: Another DRAFT Agenda
After a flurry of mail we have an updated DRAFT Agenda
Monday, January 16
7:30am - ISO discussion, Chart room
We've found copying facilities to be very expensive at hotels. We intend not
to use their facilities. Please mail copies of reports to Liz Anne's
attention at the hotel if you intend to distribute reports to the meeting.
Participants are encouraged to bring copies of reports mailed to them to the
meeting.
X3J13 Committee Meeting Agenda DRAFT
January 16 - 18, 1988
1 Call to Order, January 16, 9:00am Chart Room
2 Opening Remarks and Introductions
- Opening Remarks, Bob Mathis (10 minutes)
- Introduction of attendees
- Future meetings, Jan Zubkoff (5 minutes)
3 Approval of Agenda
4 Approval of Minutes
5 Other Business
6 Chapter 3 CLOS, Gregor Kiczales (1 hour)
7 Coffee Break 10:30
8 Chapter 3 CLOS, Gregor Kiczales (1 hour)
9 LUNCH 12:00 Voyage Room Restaurant
10 Editorial Subcommittee Report, Kathy Chapman (1 hour)
11 Compiler Subcommittee, Sandra Loosemore (2 hours)
12 Recess 3:00
13 Call to Order, 8:00pm
14 Iteration Subcommittee Report, Jonl White (30 minutes) 89-004
15 Other Subcommittee Reports
16 Recess 10:00
17 Call to Order, January 17, 9:00am Chart Room
18 Other Subcommittee Reports
19 Coffee Break 10:30am
20 Cleanup Subcommittee, Larry Masinter
21 Lunch 12:00 Voyage Room Restaurant
22 Cleanup continuation
23 Break 3:00
24 Cleanup continuation
25 Recess 4:30pm
26 Luau 6:45pm
27 Call to Order, January, 18 9:00am Paddle Room
28 Cleanup continuation
29 Coffee Break 10:30
30 Character Subcommittee Report, Thom Linden (1 hour)
31 Lunch, 12:00 Voyage Room Restaurant
32 Cleanup continuation
33 Recess, 3:00pm
34 Call to Order, January, 18 7:00pm
35 Cleanup continuation
36 Adjournment
∂11-Jan-89 1435 @Score.Stanford.EDU:jle@Orange.stanford.edu CS Colloquium
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Jan 89 12:38:29 PST
Received: from Orange.stanford.edu by SCORE.STANFORD.EDU with TCP; Wed 11 Jan 89 09:03:15-PST
Received: by Orange.stanford.edu (5.59/25-eef) id AA00660; Wed, 11 Jan 89 09:03:24 PDT
Date: Wed, 11 Jan 89 09:03:24 PDT
From: Jeffrey Eppinger <jle@Orange.stanford.edu>
Message-Id: <8901111703.AA00660@Orange.stanford.edu>
To: csd-list@score, csd@score
Subject: CS Colloquium
Bernardo Huberman
Xerox Palo Alto Research Center
The Ecology of Computation
Tuesday, January 17, 1989, 4:15pm
Psychology 040
Bernardo Huberman will be the first speaker at this quarter's Computer
Science Colloquium. His abstract is to follow. Dr. Huberman's interests
include theories of computational ecologies and chaos theory.
Please come and initiate this renewed tradition. Refreshments will be
served at 3:45pm in the third floor lounge of Margaret Jacks. If you
would like to meet with Dr. Huberman on Tuesday afternoon, please send
mail to Joyce Chandler (chandler@score).
∂11-Jan-89 1441 @polya.Stanford.EDU:phipps@solitary.Stanford.EDU new meeting time
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Jan 89 12:44:54 PST
Received: from Solitary.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA04425; Wed, 11 Jan 89 11:51:33 PDT
Received: by solitary.Stanford.EDU (5.51/inc-1.01)
id AA04018; Wed, 11 Jan 89 11:50:42 PST
From: Geoff Phipps <phipps@solitary.Stanford.EDU>
Message-Id: <8901111950.AA04018@solitary.Stanford.EDU>
To: nail@polya.stanford.edu
Subject: new meeting time
Date: Wed, 11 Jan 89 11:50:41 PST
I just noticed, it conflicts with the CSD colloquim.
I'd like to go to some of them.
g
∂11-Jan-89 1441 lansky@ai.sri.com Of possible interest....
Received: from Warbucks.AI.SRI.COM ([192.12.5.20]) by SAIL.Stanford.EDU with TCP; 11 Jan 89 12:48:19 PST
Received: from venice.ai.sri.com by Warbucks.AI.SRI.COM with INTERNET ;
Wed, 11 Jan 89 12:31:17 PST
Received: by venice.ai.sri.com (3.2/4.16)
id AA02626 for planlunch@ai.sri.com; Wed, 11 Jan 89 12:31:21 PST
Date: Wed, 11 Jan 89 12:31:21 PST
From: lansky@Warbucks.AI.SRI.COM (Amy Lansky)
Message-Id: <8901112031.AA02626@venice.ai.sri.com>
To: planlunch@Warbucks.AI.SRI.COM
Subject: Of possible interest....
(If you have questions, send a message to Barbara Simons: SIMONS@IBM.COM)
FEDERAL FUNDING OF THE ACADEMIC PHYSICAL SCIENCES
PANELISTS
Prof. Philip Anderson (Nobel Prize)
Physics, Princeton University
Prof. Richard Karp (Turing Award)
Computer science, U.C. Berkeley
Prof. Robert Park
Executive Director, Office of Public Affairs, The American Physical Society
Dr. Burton Richter (Nobel Prize)
Director, SLAC
Dr. Robert M. Rosenzweig
President, Association of American Universities
Prof. William Thurston (Fields Medal)
Mathematics, Princeton University
Moderator: Dr. Barbara Simons
Computer Science, IBM Almaden Research Center
Abstract: Federal funding of science is a major component of science policy.
Which areas are funded, how much funding they receive, which agencies do the
funding, and who makes the decisions are important issues. Fields prosper and
decline according to these decisions. Graduate students' choice of specialty
is influenced by funding. Teaching loads and even tenure decisions can be
affected. Since funding has a profound influence on technology, funding
policy has significant economic repercussions. It also has political
repercussions, as politicians become increasingly involved with the funding
process. Scientific and academic freedom are at issue. Researchers who fear
that their funding may be cut for political reasons, even if the fears are
unfounded, may engage in self-censorship.
What should be national funding priorities?
What has been the effect of the increased emphasis on 'big science' in recent
years?
How have the trends toward mission oriented and defense oriented funding
affected the quality and nature of scientific research?
Is there an imbalance of funding sources for some scientific disciplines, and,
if so, is this a problem?
What impact has science funding policy had on universities, faculty, and
graduate students?
Have government policies with respect to science funding been in the best
interest of science?
Are there ways in which these policies can be improved?
Date: Tuesday Jan. 17, 1989
Time: 8:30 A.M. - 11:30 A.M.
Place: the California East Room of the St. Francis Hotel, San Francisco
Sponsored by: the American Association for the Advancement of Science, the
American Physical Society, and the American Association of Physics Teachers
The panel is a part of several parallel conferences, namely the AAAS, the APS,
and the AAPT. I don't know whether or not one can walk in without having
registered at one of these conferences. It is possible to register at the APS
conference for a single day for $50. There is a student registration fee for
the entire AAAS conference of $50 or $70, for members and non-members
respectively.
∂11-Jan-89 1510 byrd@sumex-aim.stanford.edu Cm* book
Received: from sumex-aim.stanford.edu by SAIL.Stanford.EDU with TCP; 11 Jan 89 15:02:01 PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA06715; Wed, 11 Jan 89 15:00:44 PST
Date: Wed, 11 Jan 1989 15:00:44 PST
From: Greg Byrd <byrd@sumex-aim.stanford.edu>
To: aap@sumex-aim.stanford.edu
Subject: Cm* book
Message-Id: <CMM.0.88.600562844.byrd@sumex-aim.stanford.edu>
I have a book on my desk, "Parallel Processing: The Cm* Experience,"
which was placed on my desk a long time ago -- I was told that it
was circulating through the AAP. I don't know who's seen it, or
who's interested in seeing it. If you'd like to take a look, let
me know -- otherwise, I'll turn it over to Bob.
...Greg
∂11-Jan-89 1516 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: Urgent: announcement of panel on funding
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Jan 89 13:55:04 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA12900; Wed, 11 Jan 89 13:54:17 PDT
Message-Id: <8901112154.AA12900@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Wed, 11 Jan 89 13:53:41 PST
Received: by BYUADMIN (Mailer R2.01A) id 8447; Wed, 11 Jan 89 14:52:09 MST
Date: Wed, 11 Jan 89 15:37:21 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Ravindran.Kannan%THEORY.CS.CMU.EDU@Forsythe.Stanford.EDU
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
From: Ravindran.Kannan%THEORY.CS.CMU.EDU@Forsythe.Stanford.EDU
Subject: Re: Urgent: announcement of panel on funding
Comments: To: TheoryNet List <THEORYNT@VM1.NoDak.EDU>, simons@IBM.COM
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
In-Reply-To: TheoryNet List , simons@IBM.COM's mail message of Tue,
10 Jan 89 15:47:40 PST
thanks for the panel discussion announcement. i guess i cannot make it!
Happy new year etc. ravi
∂11-Jan-89 1605 eaf@sumex-aim.stanford.edu Re: Cm* book
Received: from sumex-aim.stanford.edu by SAIL.Stanford.EDU with TCP; 11 Jan 89 16:05:37 PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA08833; Wed, 11 Jan 89 16:04:12 PST
Date: Wed, 11 Jan 1989 16:04:11 PST
From: Edward A. Feigenbaum <eaf@sumex-aim.stanford.edu>
To: Greg Byrd <byrd@sumex-aim.stanford.edu>
Cc: aap@sumex-aim.stanford.edu
Subject: Re: Cm* book
In-Reply-To: Your message of Wed, 11 Jan 1989 15:00:44 PST
Message-Id: <CMM.0.88.600566651.eaf@sumex-aim.stanford.edu>
Greg, when everyone is done with the book, it should be given to
the relevaqnt person (I dont know who that is these days) for
cataloged entry into the Waterman Reading Room collection.
Ed
∂11-Jan-89 1649 X3J13-mailer Issue: IEEE-ATAN-BRANCH-CUT (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 16:49:27 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 89 16:43:33 PST
Date: 11 Jan 89 16:43 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: IEEE-ATAN-BRANCH-CUT (Version 2)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890111-164333-11134@Xerox>
!
Forum: Cleanup
Issue: IEEE-ATAN-BRANCH-CUT
References: CLtL p.203-214
Related issues: COMPLEX-ATAN-BRANCH-CUT
Category: CHANGE
Edit history: Version 1, 13-Dec-88, Steele
Version 2, 11-Jan-89, Masinter (1st => 3rd person)
Problem description:
If an implementation provides a floating-point minus zero as well as a
floating-point plus zero, most notably as in IEEE 754 floating-point
arithmetic, then slight adjustments in the branch cuts of transcendental
functions are appropriate.
If there is a minus zero and a plus zero, then *no* complex number
is actually "on the axis" whether real or imaginary. Instead,
numbers of the form x+0i and x-0i straddle the real axis, and those
of the form 0+xi and -0+xi straddle the imginary axis. Branch cuts
that lie on the axes therefore run between such numbers, and directions
of continuity are not an issue.
Proposal (IEEE-ATAN-BRANCH-CUT:SPLIT):
Redefine the branch cut for two-argument ATAN, covering
the cases where there is or is not a minus zero, and then redefine *all*
other functions that have branch cuts in terms of two-argument ATAN.
Specifically, first define PHASE in terms of two-argument ATAN,
and complex ABS in terms of real SQRT (which has no branch cut problems);
then define complex LOG in terms of PHASE, ABS, and real LOG; then define
complex SQRT in terms of LOG; and then define all others in terms of these.
In this propoal Lisp expressions should be taken as mathematical
formulas that actually are implemented in other ways for improved accuracy.
(1) If there is no minus zero, two-argument ATAN behaves as in CLtL.
If there is a minus zero, then some cases are modified:
Condition result
y=+0 x>0 +0
y=-0 x>0 -0
y=+0 x<0 +pi
y=-0 x<0 -pi
y=+0 x=+0 +0
y=-0 x=+0 -0
y=+0 x=-0 +pi
y=-0 x=-0 -pi
The range of two-argument atan therefore includes -pi in this case.
Note that the case y=0 x=0 is an error in the absence of minus zero,
but is defined in the presence of minus zero.
(2) (PHASE X) = (ATAN (IMAGPART X) (REALPART X)), as before, but now
the range of PHASE may include -PI if there is a minus zero.
(3) (ABS X) = (SQRT (+ (* (REALPART X) (REALPART X))
(* (IMAGPART X) (IMAGPART X)))), as before
(4) (LOG X) = (COMPLEX (LOG (ABS X)) (PHASE X))
(5) (SQRT X) = (EXP (/ (LOG X) 2))
(6) For EXPT, ASIN, ACOS, ATAN, ASINH, ACOSH, ATANH use the formulas
in CLtL pp. 211-213, but use the formulas (1-5) above as the
definitions of LOG and SQRT in order to determine the branch cuts
properly.
Examples:
(LOG #c(-1.0 +0.0)) => #c(0.0 3.14159...) ;Current
(LOG #c(-1.0 -0.0)) => #c(0.0 3.14159...) ;Current
(LOG #c(-1.0 +0.0)) => #c(0.0 3.14159...) ;Proposed (= current)
(LOG #c(-1.0 -0.0)) => #c(0.0 -3.14159...) ;Proposed (conjugate)
Rationale:
The current specification ignores some natural consequences of IEEE
floating-point arithmetic. The proposed specification produces results
more natural to that arithmetic.
Current practice:
Of implementations that support a minus zero that I have checked,
such as Sun-4 CL 2.1.3 of 10-Nov-88 and Symbolics CL, all follow
the current CLtL specification.
The IEEE trig library atan2 routine written by K.C. Ng (with the advice
or supervision of W. Kahan, I believe), and distributed with BSD UNIX
(it is file /usr/src/usr.lib/libm/IEEE/atan2.c on my machine) follows
this proposal for treatment of minus zero.
Cost to Implementors:
Some of the trig routines will require some rewriting. Probably certain
tests that are now written using ZEROP need to be rewritten to use
FLOAT-SIGN instead.
Cost to Users:
It is barely conceivable that some user code could depend on this.
Probably there is no cost.
The compatibility note on p. 210 of CLtL gave users fair warning that
a change of this kind might be adopted.
Cost of non-adoption:
Unnatural treatment of some functions on machines supporting IEEE
floating-point arithmetic.
Benefits:
Natural treatment, etc.
Esthetics:
A toss-up, except to those who care.
Discussion:
Steele has sent a letter to W. Kahan at Berkeley to get any last
comments he may have on the matter.
∂11-Jan-89 1703 X3J13-mailer Issue: LISP-PACKAGE-NAME, (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 17:03:01 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 89 16:52:58 PST
Date: 11 Jan 89 16:52 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: LISP-PACKAGE-NAME, (Version 1)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890111-165258-11168@Xerox>
!
Issue: LISP-PACKAGE-NAME
References: 11.6 Built-in Packages (pp181-182)
Category: CHANGE
Edit history: 22-Dec-88, Version 1 by Pitman
Problem Description:
Since ANSI Common Lisp will differ from the Common Lisp described by CLtL,
it will not be possible to have support for both in the same Lisp image
if ANSI Common Lisp insists on placing its functionality in the package
named LISP.
Further, use of the name unqualified name LISP by the ANSI Common Lisp
community is inconsistent with ANSI's expressed position to ISO that
the term "LISP" names a language family rather than a specific dialect
within that family.
Proposal (LISP-PACKAGE-NAME:COMMON-LISP):
Define that ANSI Common Lisp uses the package name COMMON-LISP, not LISP.
Define that the COMMON-LISP package has nickname CL.
Since some symbols (e.g., T, NIL, and LAMBDA) might have to be shared
between COMMON-LISP and LISP in implementations simultaneously supporting
both, clarify that the initial symbols specified by ANSI Common Lisp as
belonging in the COMMON-LISP package need not have a home package of
Common-Lisp.
Test Case:
In an implementation supporting CLtL's LISP package and
the ANSI Common Lisp CL package proposed here:
(EQ 'LISP:T 'CL:T)
=> not specified, due to this proposal, but probably T
(EQ 'LISP:CAR 'CL:CAR)
=> not specified, due to this proposal, but probably T
(EQ 'LISP:FUNCTIONP 'CL:FUNCTIONP)
=> not specified, due to this proposal, but since FUNCTIONP is
changed incompatibly between CLtL (LISP) and CL (ANSI), there
are good reasons why this might return NIL.
(SYMBOL-PACKAGE 'CL:T)
=> not specified, due to this proposal. Perhaps #<Package CL>,
perhaps #<Package LISP>, or perhaps something implementation-specific.
(SYMBOL-PACKAGE 'LISP:T)
=> not specified, not due to this proposal, but because CLtL didn't
specify this explicitly.
Rationale:
In practice, some implementations will have very legitimate reasons for
wanting to Lisp dialects to be coresident. As it stands, they will have
little other choice than to make the two use different packages, and so
will be forced to be incompatible with one or the other dialect unless
we choose a different package name for the one dialect for which there
is currently no existing code.
Not only is this important the CLtL and ANSI Common Lisp communities, but
also, if we continue to use the name LISP, it sends a signal to the ISO
Lisp community that the "latest and greatest" Lisp should use the generic
name LISP, and they may try to use it as well. If ISO Lisp turns out to
be very different than ANSI Common Lisp, there may be motivation down the
line for having ISO Lisp and ANSI Common Lisp co-resident, and conflicts
will inevitably arise if both want to use the name LISP. This will almost
certainly lead to a confrontation where one Lisp dialect tries to force
the other out by the artificial means of asserting its right to this
generic name. Choosing a name which compatibly admits the option of
introducing other dialects into the environment at a later date without
conflict is a good way to avoid a class of potential problems.
Although there are a few problems which could come up due to the symbol
package of initial symbols being unspecified, experience with
implementations that do this suggests that they are very few.
Problems occur only in the rare circumstance that all of the following
conditions are met:
- A symbol S on the LISP package but with home package H (that is not "LISP")
is shadowed in some package P of implementation A.
- A program F in package P uses the shadowed symbol H:S by an explicit
LISP: or H: package qualification. (Only the case of using "LISP:" is
interesting, of course, since if H were named explicitly, we would be
outside the bounds of portable code).
- The program F, referring to H:S, is printed out in implementation A
while using package P (or some other package that shadows S, so that
the H package qualifier appears explicitly) and an attempt is made to
re-read it in implementation B.
- Implementation B has no package named H, has a package named H but no
external symbol named S, or has a package named H with external symbol
S but the symbol H:S has different semantics in implementation B than
it did in implementation A.
In practice, this hardly ever happens. It would happen even less if
programmers were explicitly alerted that it was a potential problem they
needed to guard against.
Current Practice:
Symbolics Genera already has a package named COMMON-LISP with nicknames
CL and LISP. As such, this would be an incompatible change for Genera.
Cost to Implementors:
Small.
In some cases, this may even have `negative cost' because it will provide
implementors a way of avoiding incompatible changes to released operators.
Cost to Users:
Small.
In some cases, this may even have `negative cost' because existing code
would be able to continue to run in implementations which chose to support
both CLtL's LISP and ANSI Common Lisp's CL packages, thereby allowing
developers to put off a massover changeover, perhaps doing the transition
more incrementally.
Cost of Non-Adoption:
Implementations trying to support multiple dialects in the same environment
would be forced to violate one or the other spec.
Worse, different implementations faced with the same set of hard choices
about which spec to violate in order to concurrently support two dialects
might not make the same choices, leading to even more gratuitous
incompatibility.
ANSI's position in ISO that we are not trying to legislate the meaning of
-the- LISP dialect would be weakened.
Benefits:
Needless incompatibility would be avoided in a variety of situations.
Aesthetics:
Failing to specify the home package of symbols in the LISP and CL packages
seems unaesthetic because it appears to diminish print/read invertability,
but as observed above, that case is rare.
Failiing to specify a way in which lisp dialects can be co-resident is also
unaesthetic because in practice implementors with a need to do this will do
so whether the standard allows them or not, and it will be a source of
severe divergence among implementations.
Discussion:
Symbolics Genera offers two co-resident dialects of Lisp: Zetalisp and
Symbolics Common Lisp. The Symbolics Cloe development environment adds
a third co-resident dialect, making an environment in which two differing
Common Lisp dialects (Symbolics Common Lisp and Cloe) must cooperate.
Already in Cloe it is not possible for the home package to contain
package "LISP" since Cloe's concept of what the "LISP" package is differs
from Genera's concept of what the "LISP" package is, yet they are forced
by efficiency constraints to share the same symbol. It is Pitman's belief,
based on extensive experience with Cloe, that failure to pass this proposal
(or something very like it) will lead to all sorts of trouble for Common
Lisp users and implementors down the road.
Pitman strongly supports this proposal.
Additional comments:
Is it permissible for implementations to define
"LISP" as a nickname for this package, for the
sake of backward compatibility?
Anyone wanting to make LISP a nickname could just as well create a LISP
package which simply imported the appropriate symbols from the CL package.
With only modest additional effort, they could try to make new symbols where
feasable (especially for most functions) and put borrowed functions plopped
in their function cells. The amount of additional storage is small (compared
to implementing a whole new lisp), but it would leave open the possibility for
users upgrading the level of compatibility without hurting the core
system. eg, if I wanted APPEND to signal an error on dotted lists, I
would not consider redefining the system's APPEND for fear of breaking
the world, but if they told me that nothing depended on LISP other than
compatibility code, I might feel ok about redefining (or doing
SHADOWING-IMPORT of LISP:APPEND on a per-implementation basis (with
appropriate sharp conditionals)) in order to up the level of
compatibility.
In fact, though, my guess is that implementations which are not going to
do a serious compatibility effort are better off leaving the package
missing. My experience has been that customers are often happier growing
their own compatibility [or getting it from a public library] than being
stuck with something which really doesn't do what they want but which
seals off the place in the namespace which they needed in order to do
their own thing.
∂11-Jan-89 1731 hoffman@csli.Stanford.EDU the Symbolic Systems Forum Schedule Winter 89
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Jan 89 17:31:25 PST
Received: by csli.Stanford.EDU (4.0/inc-1.0)
id AA22112; Wed, 11 Jan 89 17:14:47 PST
Date: Wed 11 Jan 89 17:14:46-PST
From: Reid Hoffman <HOFFMAN@CSLI.Stanford.EDU>
Subject: the Symbolic Systems Forum Schedule Winter 89
To: AboutTheForum@CSLI.Stanford.EDU
Message-Id: <600570886.0.HOFFMAN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
Here is the Finalized Schedule for the Symbolic Systems Forum for
Winter Quarter
Jan. 20th: Professor Stan Rosenschein, "The Prospects in and of Artificial
Intelligence
Jan. 27th: Professor Peter Sells, "Quantification in Natural Language"
Feb. 3rd: Professor Jerry Feldman, "The different flavors of
Connectionism"
Feb. 10th: Professor Bernardo Huberman, "The Ecology of Computation"
Feb. 17th: Professor David Wellbery, "Semiotics"
Feb. 24th: Professor Solomon Feferman, "Turing's Oracle"
Mar. 3rd: Doctor Jeffry Shrager, undecided
Mar. 10th: Doctor Ruben Kleiman, "Ontology and Computer Science"
-------
∂11-Jan-89 1815 emma@csli.Stanford.EDU CSLI Calendar, January 12, 4:11
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Jan 89 18:14:56 PST
Received: by csli.Stanford.EDU (4.0/inc-1.0)
id AA22126; Wed, 11 Jan 89 17:15:11 PST
Date: Wed, 11 Jan 89 17:15:11 PST
From: emma@csli.Stanford.EDU (Emma Pease)
Message-Id: <8901120115.AA22126@csli.Stanford.EDU>
To: friends@csli.Stanford.EDU
Subject: CSLI Calendar, January 12, 4:11
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
12 January 1989 Stanford Vol. 4, No. 11
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
ANNOUNCEMENT
TINLunches will be scheduled irregularly during winter quarter; watch
the Calendar for announcements. The 2:15 seminar will not meet during
winter quarter, but will resume spring and fall quarters as follows:
Thursday 2:15 Seminar, Spring 1989
Varieties of Context
led by
Jim Greeno, Brian Smith, Susan Stucky
Everyone talks about context these days -- and about the "contextual
dependence" of language, information, and action. But are they
getting at the same thing? This seminar will survey various different
kinds of context (physical, cognitive, linguistic, processing), and
examine what people are saying about each. We'll be looking for
similarities among them, but also for differences.
Thursday 2:15 Seminar, Fall 1989
Models of Rational Agency
led by
Michael Bratman, Martha Pollack, Stan Rosenschein
This seminar will survey models of intelligent, rational agents
situated in dynamic, multi-agent environments.
____________
STASS SEMINAR
Thursday, January 12, 4pm
Cordura Conference Room
This quarter the STASS seminar will work through papers accepted for a
forthcoming STASS Conference. The papers vary in topic from
linguistics, to philosophy, to logic and mathematics. The seminar is
open to anyone who wants to attend, though some familiarity with
situation theory and situation semantics is presumed. The meetings
will be held on Thursdays at 4 pm in the Cordura Conference Room. The
first meeting will be on January 12, where we will set up a schedule
for the quarter. Participants are expected to present at least one
paper to the group.
____________
STANFORD UNIVERSITY INTERDISCIPLINARY COLLOQUIUM SERIES:
Adaptive Networks and their Applications
Connectionism and the Facts of Human Language
Steven Pinker
Department of Brain & Cognitive Sciences
Massachusetts Institute of Technology
(steve@psyche.mit.edu)
(with commentary by David Rumelhart)
Thursday, 12 January, 3:30pm
Room 380-380F
Connectionist modeling holds the promise of making important
contributions to our understanding of human language. For example,
such models can explore the role of parallel processing, constraint
satisfaction, neurologically realistic architectures, and efficient
pattern-matching in linguistic processes.
However, the current connectionist program of language modeling
seems to be motivated by a different set of goals: reviving classical
associationism, eliminating levels of linguistic representation, and
maximizing the role of top-down, knowledge-driven processing.
I present evidence (developed in collaboration with Alan Prince)
that these goals are ill-advised, because the empirical assumptions
they make about human language are simply false. Specifically,
evidence from adults' and children's abilities with morphology,
semantics, and syntax suggests that people possess formal linguistic
rules and autonomous linguistic representations, which are not based
on the statistical correlations among microfeatures that current
connectionist models rely on so heavily.
Moreover, I suggest that treating the existence of
mentally-represented rules and representations as an empirical
question will lead to greater progress than rejecting them on a priori
methodological grounds. The data suggest that some linguistic
processes are saliently rule-like, and call for a suitable
symbol-processing architecture, whereas others are associative, and
can be insightfully modeled using connectionist mechanisms. Thus
taking the facts of human language seriously can lead to an
interesting rapprochement between standard psycholinguistics and
connectionist modeling.
Technical Level: These talks will be technically oriented and are
intended for persons actively working in related areas. They are not
intended for the newcomer seeking general introductory material.
Mailing lists: To be added to the network mailing list, netmail to
netlist@psych.stanford.edu. For additional information, or contact
Mark Gluck (gluck@psych.stanford.edu).
Co-Sponsored by: Departments of Electrical Engineering (B. Widrow) and
Psychology (D. Rumelhart, M. Pavel, M. Gluck), Stanford Univ.
____________
NEW PUBLICATIONS
The following reports have recently been published. They may be
obtained, or a full list acquired by writing to Trudy Vizmanos,
CSLI, Ventura Hall, Stanford, CA 94305-4115, or
publications@csli.stanford.edu.
133. Relating Models of Polymorphism
Jose Meseguer $4.50
134. Fregean Thoughts and Indexicals
Patricia Blanchette $3.50
∂11-Jan-89 2008 X3J13-mailer Ballot (finally)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 11 Jan 89 20:04:05 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa01484; 12 Jan 89 3:54 GMT
Date: Thu, 12 Jan 89 03:57:03 GMT
Message-Id: <18811.8901120357@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Ballot (finally)
To: masinter.pa@xerox.com, x3J13@sail.stanford.edu
In-Reply-To: masinter.pa@com.xerox's message of 12 Dec 88 18:16 PST
Cc: richard%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK,
rhr%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
This is the official vote for the University of Edinburgh.
Y ARGUMENTS-UNDERSPECIFIED:SPECIFY
Version 4, 21-Sep-88, Mailed 4 Dec 88
Y ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
Version 9, 31-Oct-88, Mailed 5 Dec 88
Y CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY
Version 5, 5-Dec-88, Mailed 5 Dec 88
Y CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE
Version 1, 14-Sep-88, Mailed 6 Oct 88
Y DECLARATION-SCOPE:NO-HOISTING
N DECLARATION-SCOPE:LIMITED-HOISTING
Version 4, 15-Nov-88, Mailed 9-Dec-88
NO brings LET closer to application of LAMBDA-expressions.
The "en passant" capture in LIMITED is a bit too stange.
A DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION
Version 4, 5-Dec-88, Mailed 5-Dec-88
N DECLARE-TYPE-FREE:ALLOW
Y DECLARE-TYPE-FREE:LEXICAL (v 9)
Version 8, 7-Dec-88, Mailed 9-Dec-88
LEXICAL is consistent with SYMBOL-MACROLET-DECLARE:ALLOW.
A DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE
Version 2, 30-Sep-88, Mailed 6 Oct 88
Y DEFPACKAGE:ADDITION
Version 7, 2-Nov-88, Mailed 5 Dec 88
I DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
Version 2, 21-Sep-88, Mailed 6 Oct 88
If ammended as suggested by Kim Barrett.
Y DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
Version 3, 7 Dec 88, Mailed 12-Dec-88
Y DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR
Version 4, 31-Oct-88, Mailed 12-Dec-88
A DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE
A DESCRIBE-INTERACTIVE:NO
Version 4, 15-Nov-88 , Mailed 7-Dec-88
Y DOTTED-MACRO-FORMS:ALLOW
Version 3, 15-Nov-88, Mailed 7-Dec-88
I voted yes beacuse subforms can be dotted, but I don't really like it.
I EQUAL-STRUCTURE:STATUS-QUO
Version 5, 1-Oct-88, Mailed 8 Oct 88
If the EQUALP problems are cleared up.
N EXIT-EXTENT:MINIMAL
Y EXIT-EXTENT:MEDIUM
Version 5, 12-Dec-88, Mailed 12-Dec-88
Y EXPT-RATIO:P.211
Version 3, 31-Oct-88, Mailed 7 Dec 88
Y FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION
N FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM
Version 4, 7-Dec-88, Mailed 12-Dec-88
I prefer to retain a name for the non-fixnums.
I favor retaining FIXNUM because it allows me to do a useful thing
(request integers that can be handled with a certain degree of
efficiency) in the same way in all implementations that provide it.
Note that there is a large class of implementations in which fixnums
are large enough to contain the address part of a pointer and so
can be used in every case where I count objects or index structures.
Again, I prefer to be able to use the same declaration in all of these
implementations.
Not all code is meant to be portable to all Common Lisps.
Moreover, if efficiency is my concern, an explicit subrange is
actually less portable, because I cannot specify its representation.
Y FORMAT-E-EXPONENT-SIGN:FORCE-SIGN
Version 2, 2 Oct 88, Mailed 6 Oct 88
Y FORMAT-PRETTY-PRINT:YES
Version 7, 15 Dec 88, Mailed 7 Dec 88
Y FUNCTION-COMPOSITION:NEW-FUNCTIONS
I FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS
Version 4, 12 Dec 88, Mailed 12 Dec 88
C-AND-A if NEW-FUNCTIONS fails.
Y FUNCTION-DEFINITION:FUNCTION-SOURCE
Version 2, 09-Dec-88 , Mailed 9 Dec 88
Y FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE
Version 3, 7-Dec-88, Mailed 12-Dec-88
I think the explanation of exactly what changes could be clearer,
and I am not completely sure I understand it.
Y FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE
Version 5, 14-Nov-88 , Mailed 8-Dec-88
Y GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD
Version 2, 8 Dec 88, Mailed 8 Dec 88
I agree with the remark that the tests imply EQ will hold
when that is not actually guaranteed.
N HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER
Version 7, 8-Dec-88, Mailed 9-Dec-88
I might be convinced to change my mind, but right now I think this
proposal is premature. There is nothing very like it in the rest
of CL, and it would make more sense to wait until the need for it
has been more firmly established. I am also bothered by the use
of MACROLET. Is it really the case that functions declared INLINE
would not be enough for optimization?
Y HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS
Version 1, 11-Nov-88 , Mailed 12 Dec 88
I think this is an important clarification even though it may
not lead to extensive changes in practice. I disagree with the
suggestions that the proposal be shortened; but if it cannot
gather enought support as-is, it might be rearranged so as to
stress issues of correct use, such as the effects of destructive
operations on keys.
Moreover, an explanation at this level of detail removes one of
the most common objections to allowing :test arguments outside
the standard set, if accompanied by appropriate key transformation
functions, namely that the necessary constraints must first be
understood. It may therefore encourage implementors to provide
that extension, something I would like to see.
Y HASH-TABLE-TESTS:ADD-EQUALP
Version 2, 8-Dec-88, Mailed 8 Dec 88
It seems to me that SXHASH is not quite suitable for use with
EQUALP, and so I would like the key transformation function that
is used with EQUALP to made available to the user.
Y IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY
Version 4, 12-Dec-88, Mailed 12-Dec-88
At first I thought I'd make this conditional on DEFPACKAGE passing;
then I decided MAKE-PACKAGE would suffice.
Y LAMBDA-FORM:NEW-MACRO
Version 4, 22-Nov-88, Mailed 8-Dec-88
Y LCM-NO-ARGUMENTS:1
Version 1, 17 Oct 88, Mailed 8 Dec 88
Y LISP-SYMBOL-REDEFINITION:DISALLOW
Version 5, 22-Nov-88, Mailed 8 Dec 88
N MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT
Version 2, 8 Oct 88, Mailed 12-Dec-88
I would like any dependency on implementation-specific extensions
to be explicit.
Y MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
Version 2, 09-Jun-88, Mailed 8 Oct 88
A NTH-VALUE:ADD
Version 4, 8-Dec-88, Mailed 8 Dec 88
NTH-VALUE does not complete the set of operations on multiple values
because it extracts only one value, so I do not think it is needed
for the sake of completeness.
Y PACKAGE-CLUTTER:REDUCE
Version 6, 12-Dec-88, Mailed 12-Dec-881
A PACKAGE-DELETION:NEW-FUNCTION
Version 5, 21 nov 88, Mailed 8 Dec 88
Y PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN
Version 1 27-Jun-88, Mailed 7 Oct 88
I can understand why someone might find the need for :UNSPECIFIC
in Unix unclear, but I think that is because it is not clear what
filenames would be parsed as pathnames with :UNSPECIFIC type [*];
:UNSPECIFIC is nonetheless useful for building pathnames directly
when you know which case you want and need a way to specify it.
[*] Does a name without "." parse as type NIL or :UNSPECIFIC?
Different Unix programs use different conventions. Some are
willing to merge in a type field, others, such as the C compiler,
leave names as-is. So the "right" answer may vary.
Y PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR
Version 3, 8-Oct-88, Mailed 8 Oct 88
Y PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK
Version 3, 20 Sep 88, Mailed 8 Oct 88
Y PROCLAIM-LEXICAL:LG
Version 9, 8-Dec-88, Mailed 12-Dec-88
Under this proposal, special proclamations establish a default for
a name but, because of the lexical declaration, no longer force it
to be special everywhere. It also allows the programmer to say
that a global name is intended as a variable (i.e., references to
it are not spelling mistakes) without proclaiming it special. I
think these are important changes that should be preserved even if
this proposal fails. Another important feature is that LG references
to global variables can be fast in deep-bound implementations (since
L "searches" can be compiled away) while DG references (the only
global variables we have now) first have to look in D. Finally,
the current semantics are subtly confusing, because the specialness
of global variables occasionally shows through. For all of these
reasons, I support this proposal.
I think the most controversial change is the introduction of a
separate global environment, where before the only globals were
effectively just the global end of the dynamic env. Most of the
implementation complexity stems from this change, and it is likely
that it lies behind most objections.
A reasonable fallback, if this proposal does not pass, would be
to say that variables that are proclaimed lexical can never by
given dynamic bindings. That is, the global value would be taken
after searching L or D but not both and so would effectively be
an extension of the L or D env, case by case. This would be
somewhat unfortunate, because local lexical bindings for names
proclaimed special would still make sense (because they could be
declared lexical) but we wouldn't allow local special declarations
for names proclaimed lexical. The full proposal is better.
Y RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER
Version 3, 9-Oct-88, Mailed 14-Oct-88
Y RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL
Version 1, 14-Sep-88, Mailed 7 Oct 88
A REQUIRE-PATHNAME-DEFAULTS:ELIMINATE
Version 6, 9 Dec 88, mailed 09 Dec 88
N REST-LIST-ALLOCATION:NEWLY-ALLOCATED
Y REST-LIST-ALLOCATION:MAY-SHARE
N REST-LIST-ALLOCATION:MUST-SHARE
Version 3, 12-Dec-88, mailed 12-Dec-88
NEWLY-ALLOCATED is cleanest, but may be too disruptive.
Y RETURN-VALUES-UNSPECIFIED:SPECIFY
Version 6, 9 Dec 88 mailed 9-Dec-88
Y ROOM-DEFAULT-ARGUMENT:NEW-VALUE
Version 1 12-Sep-88 mailed 8 Oct 88
I suppose we might, instead, allow anything other than T or NIL.
That has a bit of a ternary feel to it.
[The following are mutually exclusive]
N SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
Version 3, 4-Nov-87, mailed Nov 87
N SETF-PLACES:ADD-SETF-FUNCTIONS
Version 1, 11-Nov-88, mailed 9-Dec-88
I am not yet happy with either proposal. The first seems nicer
but complicates the semantics of CL at a rather central point
and introduces nonorthogonality by allowing (SETF name) in
FUNCTION but not as the car of a form. The second looks like
a rather desperate attempt to avoid the first. Is there some
way to avoid writing names like setf:3.bar.middle.ref in the
"local function" example? (It's the 3 that looks worst.)
Y SETF-SUB-METHODS:DELAYED-ACCESS-STORES
Version 5, 12-Feb-88 mailed 8 Oct 88
Y STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS
Version 8, 8 Jul 88, Mailed 7 Oct 88
Y STEP-ENVIRONMENT:CURRENT
Version 3, 20-Jun-88, mailed 7 Oct 88
Y STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
version 2, 30-Nov-88 mailed 9 Dec 88
(expect amendment T ="true")
How many type names do not have corresponding predicates?
Y STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS
Version 6, 30-Nov-88, mailed 9 dec 88
expect amendment:
LINE-WIDTH ==STREAM-LINE-WIDTH
LINE-POSITION ==STREAM-LINE-POSITION
PRINTED-WIDTH ==STREAM-STRING-WIDTH
Y SUBTYPEP-TOO-VAGUE:CLARIFY
Version 4, 7-Oct-88, mailed 7 Oct 88
If MEMBER, AND, OR, and NOT can be handled, I'd be happier if they
were handled. This proposal is nonetheless better than the status quo.
Y SYMBOL-MACROLET-DECLARE:ALLOW
Version 2, 9-Dec-88, mailed 9 Dec 88
Goes best with DECLARE-TYPE-FREE:LEXICAL (rather than no DECLARE-
TYPE-FREE or :ALLOW). It would be unreasonable to pass this and
reject the other.
Y SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM
Version 5, 30-Nov-88, mailed 9 Dec 88
I TAGBODY-CONTENTS:FORBID-EXTENSION
Version 5, 9-Dec-88 mailed 9 Dec 88
Contents should be valid forms (including self-evaluating) or valid
tags. Duplicate tags should be an error (as in the proposal).
Y TAILP-NIL:T
Version 5, 9-Dec-88, mailed 12-Dec-88
Y TEST-NOT-IF-NOT:FLUSH-ALL
Y TEST-NOT-IF-NOT:FLUSH-TEST-NOT
Version 3, 1 Dec 88 mailed 9 dec
I don't oppose "depreciation" instead of deletion.
The functionality of REMOVE-IF-NOT should be preserved under
another name. Perhaps DELETE-IF-NOT too.
Y TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS
Version 3, 12-Dec-88, mailed 12 Dec 88
(some "bugs" in the proposal)
Y UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW
Version 2, 2-Dec-88, mailed 12-Dec-88
Y VARIABLE-LIST-ASYMMETRY:SYMMETRIZE
Version 3, 08-Oct-88, mailed 9 Dec 88
Jeff Dalton, JANET: J.Dalton@uk.ac.ed
AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
∂11-Jan-89 2233 X3J13-mailer Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 22:33:48 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 89 22:32:40 PST
Date: 11 Jan 89 22:30 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 6)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890111-223240-11606@Xerox>
A more general version of this was introduced by Touretzky but
it was rejected by X3J13. This has much more restricted proposal.
!
Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
References: Sequences (pp245-261), COERCE (p51)
Category: ENHANCEMENT
Edit history: 05-Feb-87, Version 1 by Touretzky (option GENERALIZED)
28-Apr-87, Version 2 by Pitman (add option MODIFIED)
26-Oct-87, Version 3 by Masinter (remove MODIFIED)
11-Nov-87, Version 4 by Masinter (respond to comments)
05-Feb-88, Version 5 by Masinter
06-Oct-88, Version 6 by Pitman
(revert to version 2, flush GENERALIZED option
-- which was rejected by X3J13 -- and resurrect MODIFIED)
Description:
Common Lisp provides many useful operations on lists and vectors which
don't apply to arrays.
For example, one can FILL a vector with 0's, but not an array. One can
REPLACE the contents of one vector with another, but one can't do this
for arrays. One can verify that EVERY element of a vector has some
property, but one can't do this for arrays. And so on.
The programmer who wishes to use arrays instead of vectors must give up
most of the useful tools CLtL provides for manipulating sequences, even
though there is no intuitive reason why operations like FILL, REPLACE,
and EVERY shouldn't work on arrays.
Proposal (SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:MODIFIED):
Common Lisp already provides a facility called "displaced arrays"
which can be used to overlay one array on top of a portion of another,
even if the two are of different ranks, so that the two share storage.
Emphasize this as a way of explaining the behavior of sequence
functions on certain arrays.
Modify the definition of COERCE to allow the coercion of an array to
a vector and vice versa. In keeping with p51 of CLtL, it should be an
error if the result type has a different number of elements than the
object being coerced.
Extend the definitions of sequence functions that either return their
argument sequences, return sequences which are the same shape as their
argument, or return non-sequences so that they also allow arrays iff
their action is conceptually independent of the shape of the array.
The affected functions are COUNT, SOME, EVERY, NOTANY, NOTEVERY,
FILL, REPLACE, SUBSTITUTE, NSUBSTITUTE, and MAP.
Expressly forbid arrays as arguments to other sequence functions.
These other functions are LENGTH, ELT, FIND, POSITION, REDUCE, SEARCH,
MISMATCH, REVERSE, NREVERSE, SORT, MAP, SUBSEQ, COPY-SEQ, CONCATENATE,
MERGE, REMOVE, REMOVE-DUPLICATES, DELETE, DELETE-DUPLICATES.
Rationale:
This proposal would expand rather than interfere with existing practice.
Since displaced arrays are already part of Common Lisp, the cost of the
proposed changes would be very low.
If the change is not adopted, Common Lisp programmers who wish to use
arrays will have two choices. Either they must write nested DO loops
every time they want to perform an array operation equivalent to FILL,
REPLACE, etc., or else they can build displaced vectors by hand and
pass them to the sequence functions when necessary.
This proposal extends certain sequence functions in some interesting
ways without committing us to a theory of how arrays and sequences
relate that everyone may not be happy with right now.
Cost to Implementors:
This would involve a lot of changes to functions, but all of them
presumably minor. The presence of displaced arrays in the language
already guarantees that the internal storage format needed to back
up these proposed changes is already in place.
Benefits:
Users of arrays do not have to use home-grown utilities to duplicate
functionality already primitively provided to users of arrays. The
sequence functions become useful in a variety of new situations.
Cost to Users:
This change is `upward compatible.' User code should run unmodified.
Aesthetics:
This extends certain existing sequence functions to allow arrays
as arguments in a fairly non-controversial way, leaving aside the
larger issue of whether and how to generalize the other sequence
functions.
Current Practice:
Probably no one implements this now.
Discussion:
A more general version of this was introduced by Touretzky but
it was rejected by X3J13.
The members of the Cleanup committee expressed interest in the ideas
behind this proposal but weren't sure they could accept it in the
proposed form. A rewrite to separate some of the issues more clearly
was solicited. Rees suggested this subset of Tourtezky's proposal
might be interesting.
Note that the function REDUCE is in a gray area. Many of its uses
are not position-dependent, but some are. The same argument might
be made about FIND. If people felt strongly, these too could be
extended either by fudging the conservative rule or by explicit
special case(s), but they have been omitted to be conservative.
∂11-Jan-89 2237 X3J13-mailer Issue: SPECIAL-TYPE-SHADOWING (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 22:37:36 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 89 22:36:27 PST
Date: 11 Jan 89 22:35 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: SPECIAL-TYPE-SHADOWING (Version 1)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890111-223627-11614@Xerox>
!
Issue: SPECIAL-TYPE-SHADOWING
References: CLtL pages 156, 158
Related issues: DECLARE-TYPE-FREE
Category: CLARIFICATION
Edit history: Version 1, 04-Nov-88 by David Gray
Problem description:
A Common Lisp user raised the question of whether something like the
following is legal:
(PROCLAIM '(TYPE NUMBER *X*))
(DEFVAR *X*)
(DEFUN FOO ()
(LET ((*X* T))
(DECLARE (TYPE SYMBOL *X*))
(BAR)))
Page 156 of CLtL says that a proclamation is "always in force unless
locally shadowed" and page 158 says type declarations "only affect
variable bindings", which might be interpreted to mean that the DECLARE
locally shadows the PROCLAIM. However, that interpretation would make
the global type proclamation useless because it could not be relied on
when compiling a function such as BAR.
Proposal SPECIAL-TYPE-SHADOWING:CLARIFY
Clarify that if there is a local type declaration for a special
variable, and there is also a global type proclamation for that same
variable, then the value of the variable within the scope of the local
declaration must be a member of the intersection of the two declared
types.
Rationale:
Some restriction on local type declarations for special variables is
needed in order for type proclamations to be meaningful. The wording
used here was chosen for consistency with proposal DECLARE-TYPE-FREE.
Current practice:
The TI, Symbolics, and Lucid implementations do not report any error
on the example above, but it isn't clear that they really do anything
with type declarations for special variables anyway.
Cost to Implementors:
This is unlikely to require a change in any current implementation.
Cost to Users:
Anyone who has written code like the example above would have to
modify it if compilers started enforcing this restriction.
Cost of non-adoption:
A minor ambiguity in the language specification that could confuse
users.
Performance impact:
None.
Benefits:
A clearer definition of the meaning of type declarations for special
variables.
Discussion:
This is obviously very closely related to issue DECLARE-TYPE-FREE, but
this is an ambiguity in the existing language that should be resolved
even if the language extension of proposal DECLARE-TYPE-FREE is not
accepted. Note also that DECLARE-TYPE-FREE makes no mention of type
proclamations.
Other possible resolutions of the ambiguity would be to either rule
out use of local type declarations for special variables, or to say
that the local type must be a subtype of the global type.
∂11-Jan-89 2316 X3J13-mailer Issue: THE-AMBIGUITY (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 23:16:17 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JAN 89 23:14:58 PST
Date: 11 Jan 89 23:14 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: THE-AMBIGUITY (Version 2)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890111-231458-11647@Xerox>
This issue has two proposals.
!
Forum: cleanup
Issue: THE-AMBIGUITY
References: THE (page 161)
Category: CLARIFICATION
Edit history: 21-Oct-88, version 1 by Rees
11-Jan-89, version 2 by Masinter (fix typos)
Problem description:
CLtL does not explicitly say whether the type specifier in a THE
form may be any type specifier or must be a type specifier suitable
for discrimination. Although THE is decsribed as a "declaration"
form, some CL implementations have assumed that the specifier must
be for discrimination, and disallow e.g.,
(THE (FUNCTION (T T) CONS) #'CONS)
We should either say that the implementations are right, or
explicitly say that they are wrong, since this case is easily
overlooked.
Proposal (THE-AMBIGUITY:FOR-DECLARATION):
Clarify that the type specifier in
(THE type exp)
may be any valid type specifier. In the case that exp returns one
value and type is not a VALUES type specifier, (THE type exp) is
equivalent to
(LET ((g exp))
(DECLARE (TYPE type g))
g)
where "g" is a gensym.
Proposal (THE-AMBIGUITY:FOR-DISCRIMINATION):
Clarify that the type specifier in
(THE type exp)
must be a valid type for discrimination, as for TYPEP, or it must
be of the form (VALUES type*) where type* are all valid for discrimination.
Current practice:
The Symbolics Genera and VAX LISP V2.2 interpreters signal errors for
(THE (FUNCTION (T T) CONS) #'CONS),
but this may not be intentional. CLtL would seem to allow it.
Test case:
(THE (FUNCTION (T T) CONS) #'CONS),
should return the CONS function under FOR-DECLARATION,
and should be an error under FOR-DISCRIMINATION.
Cost to implementors:
Trivial cost for THE-AMBIGUITY:FOR-DISCRIMINATION; this is a compatible
restriction.
For THE-AMBIGUITY:FOR-DECLARATION, implementations that do not
already allow arbitrary type specifiers but which want to check that
the type in a THE is satisfied would have to create an internal
version of TYPEP which could manage not to signal invalid-type-specifier
errors in those situations where TYPEP would because the type is a
declaration-only one.
Cost to users:
Users of implementations that support THE-AMBIGUITY:FOR-DECLARATION
might have to remove or change some uses of THE in their code if the
opposing alternative is adopted.
Benefits:
Either way, an ambiguity in the language specification would be clarified.
Aesthetics:
THE-AMBIGUITY:FOR-DECLARATION would seem to be more consistent with
DECLARE and with the intent of THE, which is supposed to be a way to
provide information for documentation and for the benefit of compilation.
Discussion:
Rees supports THE-AMBIGUITY:FOR-DECLARATION.
Appropriate error situation terminology must be chosen for the
situation that a THE declaration (or other declaration) is
unsatisfied, but that must be done regardless of this proposal.
This proposal would suggest that a function should be added to CL to
do the checking that THE would want to do:
(PROBABLY-TYPEP object type-spec)
[terrible name of course] returns multiple values a la SUBTYPEP: T T
if the object definitely has the type, NIL T if it definitely
doesn't, and T NIL (or NIL NIL?) otherwise. Assuming that an
interpreted THE-expression actually checks types, you could almost
define this function using the condition system and EVAL. (Ugh!)
Without PROBABLY-TYPEP, a meta-circular interpreter is more
difficult to write.
If a suitable name was found for this function, the additional
functionality could be suggested as an independent proposal, since
regardless of the outcome of this issue, the functionality is still
useful for checking DECLARE's.
Various implementation mechanisms were discussed for dealing
with THE checking.
Are there any remaining type specifiers beyond the list form
of the FUNCTION type that differ between "declaration" and
"discrimination"?
"I support FOR-DECLARATION. Lucid CL has the same bug in
the interpreter as the others (a "bug" assuming FOR-DECLARATION).
TYPEP is used to check the legality of the type specifier in THE."
In considering possible ways in which the type-checking logic
for THE and DECLARE might work, don't forget things like
(the (not (function (t t) integer)) 7),
which you would want to signal an error. I don't think this can be
done with only TYPEP and conditions.
∂11-Jan-89 2346 X3J13-mailer Issue: UNDEFINED-VARIABLES-AND-FUNCTIONS (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 23:46:43 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 89 23:45:32 PST
Date: 11 Jan 89 23:45 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: UNDEFINED-VARIABLES-AND-FUNCTIONS (Version 1)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890111-234532-11838@Xerox>
It was believed that this issue might be controversial.
!
Issue: UNDEFINED-VARIABLES-AND-FUNCTIONS
References: 5.1.2 Variables (CLtL pp55-56),
Slots (88-002R, p1-10)
Category: CHANGE
Edit history: 29-Nov-88, Version 1 by Pitman
Problem Description:
CLtL does not specify what happens if you attempt to call a named function
which is in fact undefined. In most implementations, it would be devastating to
actually jump to code which you had not verified to be a function, so this error
should be easily caught -- yet, CLtL does not guarantee that an error will be
signalled even in the safest, least fast OPTIMIZE settings.
CLtL (p56) specifies that "it is an error to refer to a variable that is unbound."
CLOS (p1-10) specifies that "when an unbound slot is read, the generic function
SLOT-UNBOUND is invoked. The system-supplied primary method for SLOT-UNBOUND
signals an error."
CLOS and CLtL are not in agreement on their treatment of unbound variables.
CLtL is very weak in that it guarantees no support for reliably detecting
and signalling an error when the error situation occurs, even in the safest,
least fast OPTIMIZE setting.
CLOS is very strong in that it forces detection of the error in all
situations -- even in the fastest, least safe OPTIMIZE setting.
The disparate positions for treatment of variables and slots should be
reconciled, either by finding a compromise or by justifying the apparent
inconsistency. The final story should explain function references as well.
Proposal (UNDEFINED-VARIABLES-AND-FUNCTIONS:COMPROMISE):
Define that reading an undefined function, an unbound variable, or
an unbound slot must be detected in the highest safety setting,
but the effect is undefined in any other safety setting. That is,
- Reading an undefined function should signal an error.
- Reading an an unbound variable should signal an error.
- Reading an unbound slot should invoke the function SLOT-UNBOUND.
By ``reading an undefined function'' in the above, we mean to
include both references to the function using the FUNCTION
special form, such as F in (FUNCTION F) and references to the
function in a call, such as F in (F X).
For the case of INLINE functions (in implementations where they are
supported), it is permissible to consider that performing the inlining
constitutes the read, so that an FBOUNDP check need not be done at
execution time. Put another way, the effect of FMAKUNBOUND of a function
on potentially inlined references to that function is undefined.
Specify that the type of error signalled when an undefined function
is detected is UNDEFINED-FUNCTION, and that the NAME slot of the
UNDEFINED-FUNCTION condition is initialized to the name of the
offending function.
Specify that the type of error signalled when a unbound variable
is detected is UNBOUND-VARIABLE, and that the NAME slot of the
UNBOUND-VARIABLE condition is initialized to the name of the
offending variable.
Introduce a new condition type, UNBOUND-SLOT, which inherits from
CELL-ERROR. This new type has an additional slot, INSTANCE, which
can be initialized using the :INSTANCE keyword to MAKE-CONDITION.
Introdue a new function UNBOUND-SLOT-INSTANCE to access INSTANCE slot.
Specify that the type of error signalled by the default primary
method for the SLOT-UNBOUND generic function is UNBOUND-SLOT,
and that the NAME slot of the UNBOUND-SLOT condition is initialized
to the name of the offending variable, and that the INSTANCE slot
of the UNBOUND-SLOT condition is initialized to the offending instance.
Test Case:
(PROCLAIM '(OPTIMIZE (SAFETY 3) (SPEED 0)))
(DEFUN FOO () X)
(FOO)
>>Error: The variable X is not bound.
...
Rationale:
This makes it easier to treat slots like variables.
This makes it possible to better rely on an unbound variable error being
signalled when one has occurred.
This makes it possible to compile out useless error checking in CLOS
code where the code is debugged and the checking is redundant.
For the case of undefined functions, blindly jumping to an undefined
function is an incredibly dangerous thing to do. Every implementation
should guarantee at least some way to get error checking of undefined
functions.
Current Practice:
Until recently, Symbolics Cloe did not ever signal an error on unbound
variable, even in the safest case. The excuse was that this was a CLtL
didn't require it, but it was sometimes an impediment to debugging.
Some benchmarks for Symbolics Cloe (which currently only claims to
implement New Flavors, not CLOS) could be faster if checking for unbound
instance variables could be optimized away.
Symbolics Genera doesn't care about safety issues in variable access
because the check can be done by microcode.
Cost to Implementors:
This change does not force a change to any current implementation, except
those which do not yet signal unbound variable or undefined function errors
even in the safest setting.
Cost to Users:
This checking might slow down some code which is written for the safest
setting yet does not need this check.
Any implementation-specific code which depended on these references not
signalling would be broken. Such code was not portable, of course.
Any CLOS code which depends on SLOT-UNBOUND being called even in low safety
settings would be broken. The amount of such code at this point is likely
to be little or none. If such cases did exist, local or global changes to
safety settings would correct the problem (at some cost in speed).
Cost of Non-Adoption:
Some important error checking would not occur.
Some important optimizations could not be done.
The language would seem internally less consistent.
Benefits:
The costs of non-adoption would be avoided.
Aesthetics:
This would regularize things a little.
Discussion:
Pitman thinks this would be a good idea.
∂11-Jan-89 2357 X3J13-mailer Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89 23:57:24 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JAN 89 23:55:59 PST
Date: 11 Jan 89 23:55 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE (Version 3)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890111-235559-11843@Xerox>
Several people endorsed a proposed change from Kim Barrett
to add &ALLOW-OTHER-KEY.
This version does that, and also adds a possibly controversial
feature of allowing arguments that don't name slots but
are only used in the computation of other (default or &AUX)
values.
For discussion.
!
Forum: Cleanup
Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
References: CLtL page 316
Category: CHANGE
Edit history: 20-Sep-88, Version 1, Peck
21-Sep-88, Version 2, Masinter, minor revisions
8-Jan-89, Version 3, Masinter
Problem description:
Currently, DEFSTRUCT constructor functions can be either the default
constructor function, with *only* keyword arguments, or it can be a
so-called "By Order of Arguments" constructor function with explicitly
*no* keyword arguments. Other functions in Common Lisp allow a free
mix of required, optional, and keyword arguments.
With the current restriction, it is necessary to hand code a function that
will accept optional and keyword arguments and parse the supplied-p
variables explicitly. Even so, it is not obvious to the casual programmer
how to provide the same semantics as defstruct does with respect to default
values and the defstruct init-forms.
Proposal: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
Allow &KEY keyword arguments in constructor forms of DEFSTRUCTs
and the &ALLOW-OTHER-KEYS token in addition to the &OPTIONAL,
&REST and &AUX arguments already allowed. Keyword arguments default
in a manner similar to that of &OPTIONAL arguments: if no default
is supplied in the lambda-list then the slot initform is used;
otherwise the slot is not initialized -- its initial value is
undefined.
If keyword arguments of the form ((key var) [default [svar]])
are specified, the "slot name" is matched with VAR (and not KEY).
Additional arguments that do not correspond to slot names but
are merely present to supply values used in subsequent initialization
computations are allowed.
Examples:
It should be possible to write forms like this:
(defstruct (foo (:constructor CREATE-FOO (a &optional b (c 'sea)
&key (d 2)
&aux e (f 'eff))))
(a 1) (b 2) (c 3) (d 4) (e 5) (f 6))
(create-foo 10) => #S(foo a 10 b 2 c sea d 2 e nil f eff)
(create-foo 10 'bee 'see :d 'dee) => #S(foo a 10 b bee c see d dee e nil f eff)
In the definition:
(defstruct (frob (:constructor create-frob
(a &key (b 3 have-b) (c-token 'c)
(c (list c-token (if have-b 7 2))))))
a b c)
the c-token argument is used merely to supply a value used in the
initialization of the c slot. The "supplied-p" arguments of
keyword arguments might be of this form.
Rationale:
This is a logical extension of the specification which makes some
programming easier.
Current practice:
Many implementations signal an error if given &KEY arguments or
arguments that are not slot names. The latest version of IIM Common
Lisp allows &KEY arguments in this manner. Envos Medley
(Xerox Common Lisp) implements the proposal.
Cost to Implementors:
The modifications to allow intermixed keywords and optionals in implementations
that don't already are likely simple.
Cost to Users:
No cost, this is upward compatible.
Cost of non-adoption:
The current situation is non-intuitive and needless restrictive.
Benefits:
Much easier for users to write the constructor function they want.
Probably implementation code would be reduced, since this would no
longer be an error.
Esthetics:
Minor improvement since it removes a needless restriction.
Discussion:
Possibly references to "By-position", "positional", and "By Order of
Arguments" constructor function might need to be changed to something else in
the standard. (They can still be called BOA-constructors, though, right? :-)
Version 2 of this proposal was on the January 1989 ballot.
----- End Forwarded Messages -----
∂12-Jan-89 0015 X3J13-mailer Issue: EQUAL-STRUCTURE, (Version 6)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 00:14:59 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 JAN 89 00:12:56 PST
Date: 12 Jan 89 00:12 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: EQUAL-STRUCTURE, (Version 6)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890112-001256-11866@Xerox>
Please see the Additional Comments at the end. Several people
noted problems with Version 5.
!
Issue: EQUAL-STRUCTURE
References: EQUAL (p80), EQUALP (p81)
Category: CLARIFICATION/CHANGE
Edit history: 18-Mar-88, Version 1 by Pitman
08-Jun-88, Version 2 by Masinter (add Benson's proposal)
23-Sep-88, Version 3 by Masinter (remove all but STATUS-QUO)
01-Oct-88, Version 4 by Masinter (fix description)
01-Oct-88, Version 5 by Pitman (correct wording, add discussion)
11-Jan-89, Version 6 by Pitman (attempt EQUALP correction)
Problem Description:
The behavior of EQUAL and EQUALP on structures is a subject of controversy.
At issue are whether these functions should descend the slots of structures
or use simply the structure's primitive identity (i.e., EQ) to test for
equivalence.
Proposal (EQUAL-STRUCTURE:MAYBE-STATUS-QUO):
Clarify that EQUAL and EQUALP do not descend any structures or data types
other than the ones explicitly specified in CLtL.
Type EQUAL Behavior EQUALP Behavior
Number uses EQL uses =
Character uses EQL uses CHAR-EQUAL
Cons descends descends
Bit-Vector descends descends
String descends descends
Pathname magic per CLtL same as EQUAL
Structure uses EQ descends
other Array uses EQ descends
Instance (Standard-Object) uses EQ descends
Hash-Table uses EQ uses EQ
Other uses EQ uses EQ
Note that the order of this table is in some cases important, with upper
entries taking priority over lower ones.
Rationale:
There seem to be as many different equality primitives as there
are applications for them. None of the possible ways of changing
EQUAL or EQUALP are flawless. Given the inability to "fix" them,
it is better to leave them alone.
Current Practice:
We are unaware of any extensions to CLtL's set of operations,
although frequently users request them.
Cost to Implementors:
Since this seems to be compatible with the status quo, none.
Cost to Users:
Same
Cost of Non-Adoption:
Ongoing controversy about whether EQUAL and EQUALP "do the right thing".
Benefits:
A feeling that EQUAL and EQUALP exist and/or do what they do because serious
consideration was given and we consciously decided on a particular resolution
to the numerous questions that have come up about them.
Aesthetics:
There seems to be wide debate about what the proper aesthetics for
how equality should work in Common Lisp. While the status quo is not
aesthetically more pleasing than the various alternatives, aesthetic
considerations vary widely. Different people model structures
differently. Sometimes the same person models structures differently in
different situations. The question of which should be descended and which
should not is a very personal one, and the aesthetic attractiveness of any
of these options will vary from person to person or application to
application.
Discussion:
An earlier version of this issue with various alternatives was distributed
at the June 1988 X3J13 meeting. Since
this is a frequently raised issue, we thought we should submit it
as a clarification although there is no change to CLtL.
Options for which we considered proposals were:
- removing EQUAL and EQUALP from the standard.
- changing EQUALP to descend structures.
- changing EQUALP to be case sensitive.
- adding a :TEST keyword to EQUAL.
- making EQUAL a generic function
All of these had some serious problems.
The cleanup committee supports option STATUS-QUO.
It would be useful if descriptions of EQUAL and EQUALP contained some sort
of additional commentary alluding to the complex issues discussed here.
The following is offered to the Editorial staff as a starting point:
Object equality is not a concept for which there is a uniquely
determined correct algorithm. The appropriateness of an equality
predicate can be judged only in the context of the needs of some
particular program. Although these functions take any type of
argument and their names sound very generic, EQUAL and EQUALP are
not appropriate for every application. Any decision to use or not
use them should be determined by what they are documented to do
rather than any abstract characterization of their function. If
neither EQUAL nor EQUALP is found to be appropriate in a particular
situation, programmers are encouraged to create another operator
that is appropriate rather than blame EQUAL or EQUALP for ``doing
the wrong thing.''
!
Additional Comments to Version 6:
Version 6 attempts to fix some of the problems noted in Version 5.
There are still some open questions. Only the "Proposal"
part has been changed since Version 5; some of the costs,
benefits & other discussion is now incorrect.
Kent says:
Please read this very carefully before voting in favor of it.
There were a lot of Yes votes for the last version, which I think
had some serious bugs in it. This would be a very bad issue for
us to screw up.
Things that might need special attention:
- Moon contends that standard practice in Symbolics Lisp is
for instances to be compared using EQ under EQUALP, not by
descending. There may be performance issues involved here.
Some agreement needs to be reached.
- Neither the previous version of the proposal nor CLtL was
clear on what happens to pathnames under EQUALP. This showed
up when I converted the presentation below. That issue should
be addressed as well.
Hopefully if this version of the proposal isn't something you want to
vote yes for, at least it's in a suitable form for easy line-item
changes interactively in the meeting.
∂12-Jan-89 0104 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 01:04:15 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 12 JAN 89 01:02:45 PST
Date: 12 Jan 89 01:02 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 4)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890112-010245-11915@Xerox>
There was debate over the meaning of the phrase
"status quo" an whether this proposal reflected it.
It wasn't a very useful debate. I hope we can avoid more
of it.
!
Issue: ADJUST-ARRAY-NOT-ADJUSTABLE
References: ADJUST-ARRAY (p297), ADJUSTABLE-ARRAY-P (p293),
MAKE-ARRAY (pp286-289)
Category: CLARIFICATION/CHANGE
Edit history: 22-Apr-87, Version 1 by Pitman
15-Nov-88, Versions 2a,2b,2c by Pitman
02-Dec-88, Version 3 by Pitman
11-Jan-89, Version 4 by Pitman
Problem Description:
The description of the :ADJUSTABLE option to MAKE-ARRAY on p288
says that ``the argument, if specified and not NIL, indicates that
it must be possible to alter the array's size dynamically after
it is created. This argument defaults to NIL.''
The description of the :ADJUSTABLE option does not say what
MAKE-ARRAY will do if the argument is unsupplied or explicitly NIL.
Some of the original Common Lisp designers assert that the
:ADJUSTABLE option exists in order to allow a user to select
between getting adjustable and non-adjustable arrays.
Others of the original Common Lisp designers assert that the
:ADJUSTABLE option existed to permit implementations in which
making all arrays adjustable was very expensive to make some
arrays not adjustable.
The former camp therefore believes that :ADJUSTABLE NIL means
that the array MUST be non-adjustable. The latter camp believes
that :ADJUSTABLE NIL means that the array MIGHT be non-adjustable.
The description of ADJUSTABLE-ARRAY-P on p293 says that it is
true ``if the argument (which must be an array) is adjustable, and
otherwise false.'' However, the description of MAKE-ARRAY makes
it clear that this is not necessarily the same as asking if
the array was created with :ADJUSTABLE T. If ADJUSTABLE-ARRAY-P
returns NIL, you know that :ADJUSTABLE NIL was supplied (or no
:ADJUSTABLE option was supplied), but if ADJUSTABLE-ARRAY-P returns
T, then there is no information about whether :ADJUSTABLE was used.
The description of ADJUST-ARRAY on pp297-298 says that it is
``not permitted to call ADJUST-ARRAY on an array that was not
created with the :ADJUSTABLE option.'' Although this sentence
is slightly ambiguous (one might argue that :ADJUSTABLE NIL
involves supplying the :ADJUSTABLE option), it is generally
interpreted to mean that ``... with :ADJUSTABLE T.''
One problem is that since ADJUSTABLE-ARRAY-P does not predicate
whether the :ADJUSTABLE option was provided, then
ADJUSTABLE-ARRAY-P is not an appropriate predicate in all
implementations to determine whether an array is adjustable.
Technically, :ADJUSTABLE NIL could create and adjustable array
(one for which ADJUSTABLE-ARRAY-P returns true), and yet
ADJUST-ARRAY might refuse to adjust it (if it had recorded a
separate bit saying whether :ADJUSTABLE T had been specified
and used that bit for ADJUST-ARRAY). Fortunately, this problem
has not been observed to occur in practice, but it is present
in principle.
A problem which comes up in practice is that some programmers
expect runtime error checking if they have done
(MAKE-ARRAY ... :ADJUSTABLE NIL) and they later try to adjust
the array using ADJUST-ARRAY. That expectation is violated by
legitimate implementations, since it is permissible for an
implementation to create an adjustable array even though it has
not been asked for, and since calling adjust array on such an
array "is an error" (and hence the behavior can be extended).
This perceived lack of error checking may become a legitimate
portability error to someone who has debugged his code in a
an implementation where :ADJUSTABLE NIL arrays might still be
adjustable and then tried ported his code to an implementation
which is more conservative in its interpretation.
Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE:DONKEY):
Define that omitting the :ADJUSTABLE option to MAKE-ARRAY or
explicitly supplying :ADJUSTABLE NIL may not guarantee a
non-adjustable array.
Define that ADJUSTABLE-ARRAY-P -must- be true of an array created
using :ADJUSTABLE T.
Define that ADJUSTABLE-ARRAY-P -might- be true of an array created
with no :ADJUSTABLE option or with :ADJUSTABLE NIL, but that it
-might- return false.
Clarify that the implication of the above is that saying that an
array A "is adjustable" means that (ADJUSTABLE-ARRAY-P A) => true.
Further clarify that the adjustability of an array has no necessary
relation to any value was given (or not given) as the :ADJUSTABLE
option in the call to MAKE-ARRAY which created the array A.
Clarify that there is no portable way to create a non-adjustable
array (that is, an array for which ADJUSTABLE-ARRAY-P is
guaranteed to return false).
Change the description of ADJUST-ARRAY to say that if an attempt
is made to adjust an array which is not adjustable (that is, an
array for which ADJUSTABLE-ARRAY-P would return false), an error
will be signalled.
Clarify that this legitimizes ADJUSTABLE-ARRAY-P as an appropriate
predicate to determine whether ADJUST-ARRAY will reliably succeed.
Rationale:
This effectively makes the status quo explicit.
While changing this to a tighter interpretation would be desirable, some
implementations have suggested that such a change might be very expensive
or impossible given their existing data storage layouts.
Although technically the changes to ADJUST-ARRAY are incompatible changes
from the spec, it's not believed that there are any implementations which
deviate, so we're still categorizing this as a clarification.
Current Practice:
Probably everyone is compatible with this proposal.
Symbolics Genera makes :ADJUSTABLE NIL arrays adjustable in most cases,
and is compatible with this proposal.
Lucid, IIM, and Symbolics Cloe make :ADJUSTABLE NIL arrays non-adjustable
in all cases, and are compatible with this proposal.
Cost to Implementors:
It's in principle possible that some implementation would have to change,
but in practice there are no known implementations that would have to change.
Cost to Users:
None. This is a fully compatible change from the user's standpoint.
Benefits:
Users would know what to expect.
Non-Benefits:
Users who expect adjusting arrays created with :ADJUSTABLE NIL to signal
an error would not get the desired error checking.
Aesthetics:
Most people believe the status quo is unaesthetic.
Discussion:
MACSYMA ran into portability problems due to the status quo.
If the issue had been documented, that would have helped.
Encouraging implementations that are able to at least make
(MAKE-ARRAY ... :ADJUSTABLE NIL) create non-adjustable arrays
where possible would help, too.
We considered proposals to incompatibly change this primitive in a
variety of ways, but the community was very split with strong proponents
and opponents of each alternate proposal.
The overriding concern driving this proposal is that Symbolics
has asserted that most of the other really interesting proposals would
likely involve a sizable cost to implementors (and their installed bases)
to implement what were judged by some as gratuitous changes from the
status quo.
Pitman wishes some of the other proposals were economically feasible to
pursue but reluctantly agrees that maintaining (and clearly documenting)
the status quo is probably the most reasonable avenue left to us.
∂12-Jan-89 0117 X3J13-mailer Issue: APPEND-ATOM (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 01:16:56 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 JAN 89 01:15:28 PST
Date: 12 Jan 89 01:09 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: APPEND-ATOM (Version 1)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890112-011528-11925@Xerox>
!
Issue: APPEND-ATOM
References: APPEND (p268)
Issue APPEND-DOTTED
Category: CHANGE/CLARIFICATION
Edit history: Version 1 06-Dec-88 by Steele
Problem Description:
The issue APPEND-DOTTED, as passed by X3J13, contains a minor technical
flaw: it can be construed as leaving undefined the case where an argument
to APPEND other than the last is an atom. The relevant paragraph of that
issue proposal is:
In the degenerate case where there is no last cons (i.e., the argument is
NIL) in any but the last list argument, clarify that the entire argument is
effectively ignored. Point out that in this situation, if the last argument
is a non-list, the result of APPEND or NCONC can be a non-list.
Here is the nit: the use of "i.e." leads one to believe that the
only degenerate case defined is that where the argument is NIL.
I suspect that "e.g." was intended, so as to make all atomic objects
ignored in other than the last argument.
Proposal (APPEND-ATOM:IGNORE):
In the degenerate case where there is no last cons (i.e., the argument
is an atom) in any but the last list argument, clarify that the entire
argument is effectively ignored. Point out that in this situation, if
the last argument is a non-list, the result of APPEND or NCONC can be
a non-list.
Proposal (APPEND-ATOM:ERROR)
In the degenerate case where there is no last cons (i.e., the argument
is an atom) in any but the last list argument, clarify that a value of
NIL is treated as an empty list and therefore effectively ignored, and
any other atom is an error. Point out that in this situation, if the
last argument is a non-list, the result of APPEND or NCONC can be a
non-list.
Examples:
Under APPEND-ATOM:IGNORE:
(APPEND '(a b) 'MOOSE '(c . d)) => (a b c . d) ;Proposed
(NCONC '(a b) 'MOUSSE '(c . d)) => (a b c . d) ;Proposed
(APPEND 'GUACAMOLE 17) => 17 ;Proposed
(NCONC 'SAUERKRAUT 17) => 17 ;Proposed
Under APPEND-ATOM:ERROR these cases would all be errors.
Rationale:
APPEND-ATOM:IGNORE makes a boundary case (a "zero-length dotted list")
consistent with other cases handled by the proposal APPEND-DOTTED:REPLACE.
APPEND-ATOM:ERROR would at least resolve a possible ambiguity.
Current Practice:
Lucid Lisp, KCL, and Symbolics Common Lisp all signal an error in both
interpreted and compiled code.
Cost to implementors:
Technically, the change for APPEND-ATOM:IGNORE should be relatively
small for those implementations which don't already implement it.
However, implementations which have microcoded APPEND or NCONC
incompatibly may find the small change somewhat painful.
Some implementations may have optimized their APPEND or NCONC to expect only
NIL when SAFETY is 0. In this case, depending on implementation details,
requiring an ATOM check rather than a NULL check may slow things down.
Cost to users:
Each proposal is upward compatible.
Benefits:
Since dotted lists are allowed as a non-last argument, readers will
probably assume that the boundary case of a zero-length dotted list
(that is, an atom) also works, something that doesn't appear to be
guaranteed by a strict reading. Proposal APPEND-ATOM:IGNORE would
happen to legitimize such assumptions.
Aesthetics:
Whether or not users will think this improves the aesthetics of the language
will depend largely on how they view the relation between lists and dotted
lists. Those who view dotted lists as a special kind of list may feel
differently than those who view lists as a special kind of dotted list.
The downside of APPEND-ATOM:IGNORE is that APPEND is supposed to
operate on lists, and it is mildly offensive to let it accept atoms,
and worse yet to ignore them. Furthermore, a certain amount of useful
error checking may be lost.
Discussion:
Guy Steele supports proposal APPEND-ATOM:IGNORE, but with some qualms.
He raises it mainly because of the possibility that
APPEND-DOTTED:REPLACE was not worded exactly as intended.
∂12-Jan-89 0121 X3J13-mailer Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 01:21:36 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 12 JAN 89 01:20:02 PST
Date: 12 Jan 89 01:19 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890112-012002-11939@Xerox>
There has been discussion on this issue not reflected in the
writeup. Some of the cost/benefit analysis misses some of the
Costs to Users, for example.
!
Status: DRAFT
Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA
Forum: Cleanup
References: Back quote (pp349-351)
Category: CLARIFICATION/CHANGE
Edit history: 22-Dec-88, Version 1 by Pitman
Problem Description:
The consistent description of backquote has been disrupted by
recent changes in the semantics of APPEND.
The description at the bottom of p350 suggests that
`(foo ,@bar) can be legitimately interpreted as any of
#1: (list* 'foo bar)
#2: (append (list 'foo) bar)
#3: (append (list 'foo) bar '())
Unfortunately, issue APPEND-DOTTED has disrupted the equivalences
here because if BAR holds a dotted list, #1 and #2 are the same (they
preserve the `dotted cdr'), but #3 is different (it replaces the
`dotted cdr' with NIL). Under CLtL, a dotted list given to APPEND was
an error, so this case did not come up. But since ANSI CL will not make
this an error, this ambiguity must be resolved.
Proposal (BACKQUOTE-COMMA-ATSIGN-DOT-COMMA:DIVERGENT):
Define that `(x1 ... xM . ,xN) is equivalent to (LIST* x1 ... xN).
The actual (EQL) object xN will be used without copying in the result.
The result itself might not be a proper list (e.g., if xN is an
atom or dotted list).
Define that `(x1 ... xM ,@xN) is equivalent to
(APPEND (LIST 'x1) ... (list 'xM) xN '()).
Any top-level list structure of the object xN will be copied in the
result, replacing (CDR (LAST xN)) with NIL (or replacing xN itself
with NIL if xN is an atom and issue APPEND-ATOM passes).
Proposal (BACKQUOTE-COMMA-ATSIGN-DOT-COMMA:INTERCHANGEABLE):
Define that `(x1 ... xM . ,xN) is equivalent to (LIST* x1 ... xN).
The actual (EQL) object xN will be used without copying in the result.
The result itself might not be a proper list (e.g., if xN is an
atom or dotted list).
Define that `(x1 ... xM ,@xN) is equivalent to
(APPEND (LIST 'x1) ... (list 'xM) xN).
The actual (EQL) object xN will be used without copying in the result.
The result itself might not be a proper list (e.g., if xN is an
atom or dotted list).
Notes:
Note well that this has implications which go beyond dotted lists.
Currently, `(FOO ,@X) may be implemented by either
(LIST* 'FOO X)
or (APPEND (LIST 'FOO) X '())
or (APPEND (LIST 'FOO) X)
A consequence of the proposals above is to distinguish between
the two APPEND cases, forcing changes in the side-effect behavior
of backquoted structures currently exhibited by some implementations.
Test Cases:
;; Issue #1: Non-side-effect treatment of dotted lists.
(LET ((DOTTED (LIST* 'A 'B 'C)))
(VALUES `(FOO ,@DOTTED)
`(FOO . ,DOTTED)))
=> (FOO A B), (FOO A B . C) ;under proposal DIVERGENT
=> (FOO A B . C), (FOO A B . C) ;under proposal INTERCHANGEABLE
;; Issue #2a: Side-effects
;; Sometimes called the ``Standard Backquote Screw''
;; Structure is unintentionally shared.
(LET ((TAIL1 (LIST 'A 'B 'C))
(TAIL2 (LIST 'A 'B 'C)))
(FLET ((GET-XABC-COMMA-ATSIGN () `(X ,@TAIL1))
(GET-XABC-DOT-COMMA () `(X . ,TAIL2)))
(LET ((TEMP1 (GET-XABC-COMMA-ATSIGN))
(TEMP2 (GET-XABC-DOT-COMMA)))
(SETF (CADDR TEMP1) 'Z)
(SETF (CADDR TEMP2) 'Z)
(VALUES TEMP1 (GET-XABC-COMMA-ATSIGN)
TEMP2 (GET-XABC-DOT-COMMA)))))
=> (X A Z C), (X A B C), (X A Z C), (X A Z C) ;under proposal DIVERGENT
=> (X A Z C), (X A Z C), (X A Z C), (X A Z C) ;under proposal INTERCHANGEABLE
;; Issue #2b: Side-effects
;; Sometimes called ``Inverse Backquote Screw''
;; Structure is unintentionally copied.
(LET ((VAR 'X)
(VAL '7)
(THE-SETQ-TAIL (LIST NIL NIL)))
(LET ((COMMA-ATSIGN `(SETQ ,@THE-SETQ-TAIL))
(DOT-COMMA `(SETQ . ,THE-SETQ-TAIL)))
(SETF (CAR SETQ-TAIL) VAR)
(SETF (CADR SETQ-TAIL) VAL)
(VALUES COMMA-ATSIGN DOT-COMMA)
=> (SETQ NIL NIL), (SETQ X 7) ; under proposal DIVERGENT
=> (SETQ X 7), (SETQ X 7) ; under proposal INTERCHANGEABLE
Rationale:
This clarifies an ambiguity in the description of the language which was caused
by issue APPEND-DOTTED and APPEND-ATOM.
Although CLtL tries not to specify the sharing and side-effect implications
of backquote, there is no really principled reason for its failure to do so.
In practice, the failure to do so leads to gratuitous portability barriers.
Current Practice:
Currently, the definition of APPEND is such that it would be an error
to pass it a dotted list, so there is no possibility of discrepancy
because the interesting case is an "is an error" case.
Cost to Implementors:
Very small. Some implementations would need to change how they implement
backquote. Presumably this is a very isolated change.
Cost to Users:
Technically, none. Existing code is not supposed to rely on the distinctions
discussed here. The distinction will only be meaningful when ANSI CL goes into
effect.
In practice, since some implementations will have to change incompatibly,
some code which accidentally relies on the current behavior will break.
However, once such code is fixed, it will be more portable because
implementations will not gratuitously diverge.
Cost of Non-Adoption:
An ambiguity would exist in the language, confusing both users and
implementors.
Benefits:
An ambiguity would be removed.
Some gratuitous barriers to portability would be removed.
Aesthetics:
Proposal DIVERGENT makes things slightly harder to learn.
Both proposals make things more predictably portable, which presumably
has some aesthetic appeal.
Discussion:
Pitman thinks that either of these choices will be better than the status quo.
Given that some people already think of ., and ,@ as interchangeable and merely
a matter of personal style, it would be better to go with option INTERCHANGEABLE.
∂12-Jan-89 1004 @Score.Stanford.EDU:laudon@Portia.stanford.edu Jan 17 federal funding panel
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Jan 89 10:03:56 PST
Received: from Portia.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 12 Jan 89 10:01:03-PST
Received: by Portia.stanford.edu (5.59/25-eef) id AA17756; Thu, 12 Jan 89 10:00:32 PDT
Date: Thu, 12 Jan 89 10:00:32 PDT
From: James Laudon <laudon@Portia.stanford.edu>
Message-Id: <8901121800.AA17756@Portia.stanford.edu>
To: csl-students@shasta, ee-faculty@sierra, faculty@score, su-events@polya
Subject: Jan 17 federal funding panel
Cc: laudon@portia
A reminder of the panel on federal funding to be held on January 17. Note
that Prof. Richard Karp has been added to the panel.
FEDERAL FUNDING OF THE ACADEMIC PHYSICAL SCIENCES
PANELISTS
Prof. Philip Anderson (Nobel Prize)
Physics, Princeton University
Prof. Richard Karp (Turing Award)
Computer science, U.C. Berkeley
Prof. Robert Park
Executive Director, Office of Public Affairs, The American Physical Society
Dr. Burton Richter (Nobel Prize)
Director, SLAC
Dr. Robert M. Rosenzweig
President, Association of American Universities
Prof. William Thurston (Fields Medal)
Mathematics, Princeton University
Moderator: Dr. Barbara Simons
Computer Science, IBM Almaden Research Center
Abstract: Federal funding of science is a major component of science policy.
Which areas are funded, how much funding they receive, which agencies do the
funding, and who makes the decisions are important issues. Fields prosper and
decline according to these decisions. Graduate students' choice of specialty
is influenced by funding. Teaching loads and even tenure decisions can be
affected. Since funding has a profound influence on technology, funding
policy has significant economic repercussions. It also has political
repercussions, as politicians become increasingly involved with the funding
process. Scientific and academic freedom are at issue. Researchers who fear
that their funding may be cut for political reasons, even if the fears are
unfounded, may engage in self-censorship.
What should be national funding priorities?
What has been the effect of the increased emphasis on 'big science' in recent
years?
How have the trends toward mission oriented and defense oriented funding
affected the quality and nature of scientific research?
Is there an imbalance of funding sources for some scientific disciplines, and,
if so, is this a problem?
What impact has science funding policy had on universities, faculty, and
graduate students?
Have government policies with respect to science funding been in the best
interest of science?
Are there ways in which these policies can be improved?
Date: Tuesday Jan. 17, 1989
Time: 8:30 A.M. - 11:30 A.M.
Place: the California East Room of the St. Francis Hotel, San Francisco
Sponsored by: the American Association for the Advancement of Science, the
American Physical Society, and the American Association of Physics Teachers
∂12-Jan-89 1413 X3J13-mailer Issue: CLOSE-CONSTRUCTED-STREAM (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 14:13:17 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 12 JAN 89 13:58:56 PST
Date: 12 Jan 89 13:58 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: CLOSE-CONSTRUCTED-STREAM (Version 2)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890112-135856-13358@Xerox>
This Issue has too many Proposals. We've not had the
time to narrow them down.
!
Status: DRAFT
Forum: Cleanup
Issue: CLOSE-CONSTRUCTED-STREAM
References: Close (CLtL p. 332), WITH-OPEN-STREAM
(CLtL p 330), make-synonym-stream, make-broadcast-stream,
make-concatenated-stream, make-two-way-stream,
make-echo-stream, make-string-input-stream,
make-string-output-stream, with-input-from-string,
with-output-from-string
Related issues: CLOSED-STREAM-OPERATIONS
Category: Clarification/Change
Edit history: Masinter, 6-Jan-89, Version 1
Masinter, 12-Jan-89, Version 2
Problem description:
First some terminology:
A "composite" stream is one created with MAKE-SYNONYM-STREAM,
MAKE-BROADCAST-STREAM, MAKE-CONCATENATED-STREAM, MAKE-TWO-WAY-STREAM,
MAKE-ECHO-STREAM.
The "constituents" of a composite stream are the streams it points to:
the SYMBOL-VALUE of the symbol given to MAKE-SYNONYM-STREAM
the streams given to MAKE-BROADCAST-STREAM or MAKE-CONCATENATED-STREAM
the input-stream and output-stream given to MAKE-TWO-WAY-STREAM or MAKE-ECHO-STREAM.
A "constructed" stream is either a composite stream or one created with
MAKE-STRING-INPUT-STREAM, MAKE-STRING-OUTPUT-STREAM, WITH-INPUT-FROM-STRING,
WITH-OUTPUT-FROM-STRING.
The function "CLOSE" is currently described in 21.3, which starts "This
section contains discussion of only those operations that are common to all
streams." This would seem to imply that they apply to constructed streams.
The definition of CLOSE "The argument must be a stream. No further input/output
operations may be performed on it. ... " It further states "... and it is
permissible to close an already closed stream."
However, the behavior on the constructed streams is not well defined, and
implementations (apparently) differ.
Proposal (CLOSE-CONSTRUCTED-STREAM:IS-ERROR):
It "is an error" to call CLOSE on a constructed stream. CLOSE might signal an
error, or the result of CLOSE could cause the constituent streams to be closed,
etc, but the effect is implementation-dependent.
Proposal: (CLOSE-CONSTRUCTED-STREAM:SIGNALS-ERROR)
Calling CLOSE on a constructed stream signals an error.
Proposal (CLOSE-CONSTRUCTED-STREAM:ARGUMENT-STREAM-ONLY):
The effect of CLOSE on a constructed stream is to close the "argument" stream
only. No i/o operations are permitted after the call to CLOSE on the stream
given to CLOSE; There is no effect on the constituents of composite streams.
For streams created with MAKE-STRING-OUTPUT-STREAM, the result of
GET-OUTPUT-STREAM-STRING is unspecified after CLOS. For composite streams,
the call to CLOSE has no effect on any of the constituent streams.
The "links" to the constituents may be broken; if the proposal in STREAM-ACCESS
passes, the results of the accessor functions there are unspecified after the
call to CLOSE.)
Proposal: (CLOSE-CONSTRUCTED-STREAM:CLOSE-CONSTITUENTS)
CLOSE first closes its argument; it then operates recursively on the constituents
of composite streams.
Examples:
>>not written; sorry<<
Rationale:
Specifying seems better than not saying what happens, even if it is
"implementation-dependent".
Current practice:
Implementations seem to vary widely.
Cost to Implementors:
Varying, depending on the current level of conformance. Making the changes
themselves is probably trivial (to the "close" method for each kind of
constructed stream type) but it is possible that system code might depend
on the behavior.
Cost to Users:
Likely small; we've not found any good uses for CLOSE on composite streams.
Cost of non-adoption:
Continued minor ambiguity
Performance impact:
near zero
Benefits:
The language would be more well specified.
Esthetics:
Well-specified languages are usually easier to deal with.
Discussion:
Signalling an error is reasonable if no Common Lisp program ever needs to
call CLOSE on a composite stream. We could not come up with a legitimate
case where you wouldn't instead close the underlying stream if that's what
you wanted.
Allowing the result to be implementation dependent is the "status quo".
ARGUMENT-STREAM-ONLY is probably the "safest" in that it makes it
harder to accidentally close a stream that wasn't intended. It
seems counterintuitive and yet it probably wouldn't be harmful
if it were well-defined that this was what it did.
CLOSE-CONSTITUENTS could be an incompatible change for some
implementations. It makes more sense for things like broadcast streams
(which are usually non-interactive) than it does for echo streams
(which are sometimes interactive).
∂12-Jan-89 1445 @Score.Stanford.EDU:weening@Gang-of-Four.Stanford.EDU USENET newsgroups for classes
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Jan 89 14:45:34 PST
Received: from Gang-of-Four.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 12 Jan 89 14:40:59-PST
Received: by Gang-of-Four.Stanford.EDU (5.59/25-eef) id AA03659; Thu, 12 Jan 89 14:39:07 PST
Date: Thu, 12 Jan 89 14:39:07 PST
From: Joe Weening <weening@Gang-of-Four.Stanford.EDU>
Message-Id: <8901122239.AA03659@Gang-of-Four.Stanford.EDU>
To: instructors@score, tas@score
Subject: USENET newsgroups for classes
Last quarter several classes used USENET newsgroups for announcements,
discussions, etc. These newsgroups are available on Unix systems
(including Portia and Polya) with the programs "readnews" and "rn",
among others, and have names such as "su.class.cs306".
If any winter quarter class would like to set up such a newsgroup,
send me a message and I will create it.
Joe
∂12-Jan-89 1526 X3J13-mailer Issue: REMF-MULTIPLE (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 15:24:48 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 JAN 89 15:11:46 PST
Date: 12 Jan 89 15:05 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: REMF-MULTIPLE (Version 2)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890112-151146-1173@Xerox>
!
Status: DRAFT
Issue: REMF-MULTIPLE
References: REMPROP (p166), REMF (p167)
Category: CLARIFICATION/CHANGE
Edit history: 26-Jan-88, Version 1 by Pitman
12-Jan-89, Version 2 by Masinter (add IS-ERROR per Moon)
Problem Description:
The descriptions of REMF and REMPROP are not explicit about what happens in
the case that a duplicated indicator occurs on the plist. One or both indicators
might be removed.
Proposal (REMF-MULITPLE:REMOVE-ONE):
Clarify that REMF and REMPROP at most one indicator/value pair from the designated plist.
Rationale:
In a property list maintained by the normal property list operations, there will
only be one property by each name. This approach won't waste time trying to remove
other properties which are not present in the first place.
Proposal (REMF-MULTIPLE:REMOVE-ALL):
Clarify that REMF and REMPROP remove all matching indicator/value pairs from the
designated plist.
Rationale:
In a property list maintained by other operations than the standard ones,
this might be useful. Also, since the return value of REMF and REMPROP is
not well-defined, iterating to remove more than one property is expensive
because you have to start over from the head of the list.
Proposal (REMF-MULTIPLE:IS-AN-ERROR):
Clarify that it "is an error" to pass a list with a duplicated
indicator to REMF or any other function that takes a
property list (including GETF); it "is an error" for a
symbol to have duplicated properties on its property list.
Rationale:
The only thing that CLtL pp 163-167 says about
duplicated indicators on plists is that there aren't any
(first line on page 164). It does not even gurantee
that GETF returns the first occurrence.
Test Case:
;; Case #1 - removing symbol properties,etc. using REMPROP
(DEFUN REMF-MULTIPLE-TEST-1 ()
(LET ((SYMBOL (GENSYM)))
(SETF (SYMBOL-PLIST SYMBOL) (LIST 'A 'B 'C 'D 'A 'B 'C 'D))
(FORMAT T "~&Before: ~S~%" (SYMBOL-PLIST SYMBOL))
(REMPROP SYMBOL 'A)
(FORMAT T "~&After: ~S~%" (SYMBOL-PLIST SYMBOL))
(FORMAT T "~&This implementation uses REMF-MULTIPLE:~:[REMOVE-ALL~;REMOVE-ONE~] ~
for REMPROP.~%"
(GET SYMBOL 'A))))
;; Case #2 - removing keywords,etc. using REMF
(DEFUN REMF-MULTIPLE-TEST-2 ()
(LABELS ((HELPER (&REST ARGUMENTS &KEY (A 1) (B 2))
(FORMAT T "~&Helper received: ~S~%" ARGUMENTS)
(LIST A B))
(DRIVER (&REST ARGUMENTS)
(FORMAT T "~&Helper received: ~S~%" ARGUMENTS)
(SETQ ARGUMENTS (COPY-LIST ARGUMENTS))
(REMF ARGUMENTS ':A)
(APPLY #'HELPER ARGUMENTS)))
(LET ((RESULT (DRIVER :A 3 :B 4 :A 5 :B 6)))
(FORMAT T "~&Returned: ~S~%" RESULT)
(FORMAT T "~&This implementation uses REMF-MULTIPLE:~:[REMOVE-ALL~;REMOVE-ONE~] ~
for REMF.~%"
(= (CAR RESULT) 5)))))
Current Practice:
Symbolics implements REMF-MULTIPLE:REMOVE-ONE.
Cost to Implementors:
For implementations needing to change, the cost of a change is probably very
small in most cases. Implementations needing change which do REMPROP and/or REMF
in microcode might have a slightly harder time, but any change should still be
very localized.
Cost to Users:
None. Users must tread lightly on this issue right now because it is not well-defined.
Cost of Non-Adoption:
The language description would continue to be vague for no particularly good reason.
Benefits:
IS-ERROR at least makes the situation more explicit. For the other proposals,
users who want to use REMPROP or REMF in situations which involve lists that might
have duplicated elements would be able to do so more reliably.
Aesthetics:
There is probably no particular aesthetic reason to think one of these solutions
is better than the other, but having the issue nailed down is probably an aesthetic
improvement.
Discussion:
This issue, first brought up in Cleanup almost a year ago, got lost.
Pitman is agnostic on this for now. There are advantages to both.
If everybody already implements REMOVE-ONE, that would seem the way to go.
"If we're going to extend Common Lisp to allow duplicated indicators on
plists, we should do it for all the property list functions, not
just REMF and REMPROP."
∂12-Jan-89 1642 X3J13-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 16:42:06 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 JAN 89 16:27:25 PST
Date: 12 Jan 89 16:26 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890112-162725-1374@Xerox>
This issue has a number of additional comments at the end.
!
Status: DRAFT
Forum: Cleanup
Issue: REMF-DESTRUCTION-UNSPECIFIED
References: (SETF (GET ...) ...), REMPROP, (SETF (GETF ...) ...),
REMF (pp165-167); NREVERSE (p248); DELETE, DELETE-IF,
DELETE-IF-NOT, DELETE-DUPLICATES, NSUBSTITUTE,
NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT (pp254-256); NCONC,
NRECONC (p269); NBUTLAST (p271); NSUBST, NSUBST-IF,
NSUBST-IF-NOT (p274); NUNION, NINTERSECTION,
NSET-EXCLUSIVE-OR (pp276-279).
Category: CLARIFICATION/CHANGE
Edit history: 11-Feb-87, Version 1 by Dave Andre (DLA@Symbolics.COM)
29-Oct-87, Version 2 by Pitman (flesh out proposals)
28-Nov-88, Version 3 by Pitman (revised presentation)
29-Nov-88, Version 4 by Pitman (slight editing per DLA)
Problem Description:
Currently, the exact nature of the side-effect performed by list
modification routines is not specified.
Either the specific modifications allowed should be specified so that
programmers can rely on them and implementors can avoid accidentally
causing problems by introducing well-meaning optimizations, or else
the documentation should explicitly state that the effects are
unspecified so that programmers will not depend on them and
implementors will feel comfortable about doing interesting optimizations.
Proposal (REMF-DESTRUCTION-UNSPECIFIED:EXPLICITLY-VAGUE):
Clarify that the way in which the destructive behavior of the
operators below is achieved is explicitly vague in a number of ways,
in order to provide individual implementations the necessary
flexibility to do useful optimizations.
(SETF (GETF place indicator) value)
is permitted to either SETF place or to SETF any part, CAR or
CDR, of the top-level list structure held by that place.
(REMF place indicator)
is permitted to either SETF place or to SETF any part, CAR or
CDR, of the top-level list structure held by that place.
(SETF (GET symbol indicator) value)
is constrained to behave exactly the same as
(SETF (GETF (SYMBOL-PLIST symbol) indicator) value).
(REMPROP symbol indicator)
is constrained to behave exactly the same as
(REMF (SYMBOL-PLIST symbol) indicator).
(NREVERSE sequence)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure in that sequence.
when sequence is an array is permitted to re-order the elements
of the given sequence in order to produce the resulting array.
(DELETE object sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure held in that sequence.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
(DELETE-IF test sequence ...)
is constrained to behave exactly like
(DELETE NIL sequence
:TEST #'(LAMBDA (IGNORE ITEM) (FUNCALL test ITEM))
...).
(DELETE-IF-NOT test sequence ...)
is constrained to behave exactly like
(DELETE NIL sequence
:TEST #'(LAMBDA (IGNORE ITEM) (NOT (FUNCALL test ITEM)))
...).
(DELETE-DUPLICATES sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure held in that sequence.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
(NSUBSTITUTE new-object old-object sequence ...)
(NSUBSTITUTE-IF new-object test sequence ...)
(NSUBSTITUTE-IF-NOT new-object test sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure in that sequence.
when sequence is an array is permitted to SETF the contents of
any cell in that array which must be replaced by NEW-OBJECT.
Note, however, that since this side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
(NCONC . lists)
is permitted to SETF any part, CAR or CDR, of the top-level of
any of the given lists (except the last, which is not required to
be a list and must not be modified).
(NRECONC list tail)
is constrained to have side-effect behavior equivalent to:
(NCONC (NREVERSE list) tail).
(NBUTLAST list ...)
is permitted to SETF any part, CAR or CDR, of the top-level of
any of the given list.
(NSUBST new-object old-object tree)
(NSUBST-IF new-object test tree)
(NSUBST-IF-NOT new-object test tree)
is permitted to SETF any part of the TREE of conses which must
be replaced by NEW-OBJECT.
Note, however, that since the tree might be a degenerate tree
containing no conses and since the side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
(NUNION list1 list2 ...)
(NINTERSECTION list1 list2 ...)
(NSET-EXCLUSIVE-OR list1 list2 ...)
is permitted to SETF any part, CAR or CDR, of the top-level of
any of the given lists.
Note, however, that since this side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
Note: The above clarifications are not intended as complete functional
descriptions. They are intended to augment (rather than to replace)
other descriptions already in effect.
Test Cases:
For GETF...
(SETQ FOO (LIST 'A 'B 'C 'D 'E 'F)) ==> (A B C D E F)
(SETQ BAR (CDDR FOO)) ==> (C D E F)
(REMF FOO 'C)
BAR ==> ??
In Symbolics Common Lisp, BAR holds (C D E F).
CLtL allows other interpretations. eg, BAR might hold
(C), (NIL), (C NIL) or (C D).
Under this proposal, any of these interpretations (and others as well)
would still be valid
For DELETE...
(SETQ FOO (LIST 'A 'B 'C)) ==> (A B C)
(SETQ BAR (CDR FOO)) ==> (B C)
(SETQ FOO (DELETE 'B FOO)) ==> (A C)
BAR ==> ??
(EQ (CDR FOO) (CAR BAR)) ==> ??
In Symbolics Common Lisp, these last two expressions return ((C)) and T.
Under this proposal, either of these interpretations (and others
as well) would be valid.
Rationale:
Implementations already vary widely on their implementation techniques
for these functions. This effectively clarifies the status quo, making
it more clear to programmers what they may rely upon in portable code.
Current Practice:
All valid implementations are believed to comply.
Cost to Implementors:
None. This is the status quo for implementors.
Cost to Users:
This change would not affect programs coded with "good programming
practice". That is, only programs which rely on currently undocumented
features would be in any danger of breaking. In fact, those programs
are already in such danger, and this change to the documentation would
just publicize it. The clarification would -encourage- good programming
practice by warning people to only obey the published contract of the
above-mentioned functions.
There is, however, no automatic technique for making this check for
programs already in error. Bugs due to unexpected side-effects are in
general among the hardest to reckon with.
Cost of Non-Adoption:
Programmers may naively believe there is only one possible or reasonable
implementation of these functions. Some implementors may shy away from
reasonable optimizations out of a paranoid belief that deviating from
some vague, unspoken rules will lead to programmer unrest. Making these
things explicitly vague clarifies the implementor's rights in a way that
permits numerous useful optimizations.
Benefits:
Users would be discouraged from taking advantage of subtle details
of these destructive operations because such details would be explicitly
not guaranteed to be portable.
Implementations can improve performance of many of the above-mentioned
functions when they are not under the constraint to implement them
in a highly constrained fashion. For example, in Symbolics systems,
DELETE of a cdr-coded list could use the implementation primitive
%CHANGE-LIST-TO-CONS rather than RPLACD to avoid creating forwarding
pointers.
Garbage collection effectiveness can also be improved. For example,
all of the destructive operations which remove objects (eg, REMF)
could remove CAR pointers to removed objects which are more volatile
than the list itself, assisting the garbage collector and thereby
improving memory usage and paging performance.
Non-Benefits:
Users who inadvertently depend on side-effect behavior may be rudely
surprised when moving between implementations.
Compatibility with older Lisp dialects is diminished.
Performance Impact:
Metering in Symbolics test systems have shown that there are substantial
performance gains to be had by allowing implementations flexibility in
these areas.
Aesthetics:
Most of these functions implement abstract operations. For example,
REMPROP implements an abstract operation on a "property list".
Proper language design should not encourage people to delve below the
level of abstraction into the nitty gritty.
Discussion:
Andre's original version of this proposal pushed for explicitly vague
descriptions of these functions' side-effect behavior. He believes
that if users want more predictability from these functions, they
should write private variants that implement whatever predictability
they require.
Pitman originally opposed this position because he weighed portability
a higher concern. Since the original discussion, however, his views on
how to resolve this priority have been refined, and he now believes
that leaving things vague is appropriate. As such, he now supports what
is effectively Andre's original proposal.
Pitman and Andre support this proposal.
!
Additional Comments:
"...I'd like to see a section in the spec that concerns these
"destructive" operations to say explicity that it is perfectly
all right for them _not_ to destroy anything but instead to
"cons" new results. ...
Change "the destructive behavior of the operators" to say
"if any".
Change the proposal by...
- striking the three or so places that it explicitly reminds you
to use SETQ in case a side-effect doesn't occur
- adding some general purpose verbiage that says something like
that the purpose of these operators is to provide you the most
efficient algorithm, and that in some situations or some
implementations, there may be some reasons why the most
efficient thing is to copy rather than to side-effect. As such
none of these operators are actually required to side-effect,
but the user should assume that, whatever the implementation, it
will have speed competitive with or surpassing a side-effecting
implementation.
SORT, STABLE-SORT, and MERGE are conspicuously
absent from the list. They should be added in as well.
Should NCONC and NBUTLAST be explicitly vague?
Whereas it seems less
useful to maintain the actual list substructure in (SETF (GETF ...) ...),
DELETE, NREVERSE, NSUBSTITUTE, etc, I can see a very useful role for the
specific semantics of these few -- that they change the cdr of a particular
cons cell -- and would question very highly the value of striving for speed
at the cost of correct semantics.
NSUBLIS seems to be missing; but I would classify it in with NSUBST,
NCONC and NBUTLAST of the previous paragraph.
- - - - -
SETF of GETF, REMF should be specified.
NCONC, NBUTLAST, NSUBLIS, NSUBST, NSUBST-IF, NSUBST-IF-NOT
should be specified.
Since the argument for explicitly-defined is portability and the utility of
reliable definitions, and the argument for explicitly-vague is performance,
we should leave things explicitly vague only where
a) it matters for performance and
b) reasonable programs would not rely on the
"defined" behavior
I believe the things I say should be explicitly-vague are the ones where
good style would avoid depending on side-effect behavior and where
performance matters, while the ones I say should be explicitly-defined,
there are reasonable applications which might rely on the explicit
definition, and no strong claims that "explicitly-vague" can make a
difference in performance.
- - - - - - - - -
The NSUBSTITUTE functions seem so "obvious" in implementation that it
seems hard to justify not explicitly specifying them. Seems to me
thatclassifying the sequence functions as a group is not of any
significance. There really are only three basic sequence functions
listed there and they are all quite different, and for different
reasons: NREVERSE wants to be explicitly-vague primarily because of the
list reversal, and for that primarily because of optimizations needed
for cdr-coded implementations; DELETE because of
cdr-deleted-element-off-front-of-list for lists and
we've-got-to-copy-the-non-adjustable-array for vectors; NSUBSTITUTE I
can only imagine so that an implementation could "cheat" and use
SUBSTITUTE, or just because it is a destructive sequence function.
- - - - - - - - - - -
Where you say
(REMF place indicator)
is permitted to either SETF place or to SETF any part, CAR or
CDR, of the top-level list structure held by that place.
you also need to say that it is an error after this operation to
reference any CONS that was formerly part of the top-level list
structure and is no longer part of it. Of course this applies not
just to REMF, but also to SETF of GETF, NREVERSE, DELETE,
DELETE-DUPLICATES, NCONC, NUNION, NINTERSECTION, NSET-EXCLUSIVE-OR,
SORT, STABLE-SORT, and MERGE and to the ones that are defined to be
equivalent to these; these are all the ones that might change
list structure rather than just replacing CAR elements.
You see, not only are these destructive functions allowed to change
the components of the conses that make up the top-level list structure
of the argument, they are also allowed to reuse the storage of those
conses for something else that isn't a cons at all. You may recall
that this was DLA's original motivation for bringing up the issue.
I strongly disagree with Larry's contention that SETF of GETF, REMF,
SETF of GET, and REMPROP are not reasonable to include in this proposal.
If anything, the property list operators have less justification for the
user to depend on the representation than (for example) DELETE, not more
justification.
I disagree with JonL's and Larry's contention that NBUTLAST is not
reasonable to include in this proposal. I think it would be reasonable
to implement NBUTLAST by sliding all the list elements to the right n
positions and then returning NTHCDR n of the original list. However,
CLtL p.271 could be interpreted as -requiring- NBUTLAST to be
implemented in terms of RPLACD of a specific cons, rather than just
mentioning that as an example; if so, I would change my mind and
agree that NBUTLAST should be excluded from this proposal.
I also believe that NCONC (and hence by implication NRECONC) is
reasonable to optimize, but on that point I could easily be swayed to
change my mind since I can't think of any really plausible
optimizations. However, CLtL doesn't offer much evidence that a
specific implementation of NCONC is required.
For the others Larry listed (NSUBST, NSUBST-IF, and NSUBST-IF-NOT), what
the proposal actually says ("is permitted to SETF any part of the TREE
of conses which must be replaced by NEW-OBJECT.") is not proposing to
allow an implementation to modify any portion of a cons other than what
CLtL requires it to modify. Perhaps that means there is no reason to
include these in the proposal because the proposal says exactly the same
thing about these that CLtL says. BTW CLtL appears to -require- a
side-effect for these rather than merely -allowing- a side-effect.
∂12-Jan-89 1647 @Score.Stanford.EDU:eyal@coyote.stanford.edu Broadcast of courses on SUNet
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Jan 89 16:47:06 PST
Received: from coyote.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 12 Jan 89 16:44:41-PST
Received: by coyote.stanford.edu; Thu, 12 Jan 89 16:41:08 PST
Date: Thu, 12 Jan 89 16:41:08 PST
From: Eyal Mozes <eyal@coyote.stanford.edu>
Subject: Broadcast of courses on SUNet
To: csd@score.Stanford.EDU, faculty@score.Stanford.EDU
I want to bring to your attention a matter that, I think, should
concern many people.
Up to last quarter, televised courses were broadcast on the SUNet video
network. This made it possible for students who live in student
housing, if they have a TV, to watch their classes at home, and, if
they have a VCR, to tape their class and then watch it without standing
in line for a machine at the library. This was a very convenient
arrangement which, as far as I can see, had no drawbacks at all.
However, some professors did object to this. As a result, the broadcast
of courses was suspended, and the School of Engineering is supposed to
make a policy decision on this question soon.
If they hear favorable opinions from faculty who teach televised
courses, this may affect their decision. Also, I talked to the person
in charge at SUNet, and he said they may soon start broadcasting only
the courses taught by faculty who say they're in favor. So, I'd like to
ask all faculty who teach, or plan to teach, televised courses: if you
approve of having your courses broadcast on SUNet, please make your
opinion known both to the School of Engineering and to SUNet.
Also, maybe the Computer Science department can make its own policy
decision, independently of the rest of the School of Engineering, in
favor of having Computer Science televised courses broadcast on SUNet?
Eyal Mozes (eyal@coyote)
∂12-Jan-89 1711 X3J13-mailer Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 17:11:34 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 JAN 89 17:04:55 PST
Date: 12 Jan 89 17:04 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890112-170455-1498@Xerox>
This issue is a generalization of PATHNAME-TYPE-UNSPECIFIC,
which it subsumes.
!
Forum: Cleanup
Issue: PATHNAME-UNSPECIFIC-COMPONENT
Forum: Cleanup
References: File System Interface (pp409-427)
Category: CHANGE
Edit history: 27-Dec-88, Version 1 by Pitman
Subsumes: Issue PATHNAME-TYPE-UNSPECIFIC
Problem Description:
In some file systems, it is inappropriate to represent particular
pathname components, either all the time or in some specialized
circumstance.
- Unix pathnames never have a version field.
- In some file systems, specifying a device and a directory means
something very different than specifying the device alone,
particularly when the device is a "logical device" that may
already imply a directory.
- Some Unix pathnames have types and others do not. For example,
it is possible to make files named "foo." and "foo" which are
distinct. CLtL (p412) specifies that the type is ``always a
string, NIL, or :WILD.'' This description is too restrictive
to be practical in this case. One of these (usually the former)
can get a type of "" but it is not clear how to represent the
other. If NIL is used, merging primitives cannot detect that the
field is filled and should not be merged against.
- ITS pathnames have either a version or a type, but never both.
"JOE;FILE 32" has a directory, a name, and a version.
"JOE;FILE TEXT" has a directory, a name, and a type.
"JOE;FILE TEXT 32" is not a possible ITS filename.
Proposal (PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN):
Permit :UNSPECIFIC as a value of the DEVICE, DIRECTORY, TYPE, or
VERSION field of a pathname for file systems in which it makes sense.
When a pathname is converted to a namestring, NIL and :UNSPECIFIC
are treated as if the field were empty. That is, they both cause the
component not to appear in the string.
When merging, however, only a NIL value for a component will be
replaced with the default for that component, while :UNSPECIFIC
will be left alone as if the field were filled.
Portable programs should expect to find :UNSPECIFIC in the device,
directory, type, or version field in some implementations.
Portable programs should not explicitly place :UNSPECIFIC in any
field, since that it might not be permitted in some situations,
but portable programs may sometimes do so implicitly.
Test Case:
;; #1: Non-portable code. This may signal an error in some
;; implementations where an unspecific type makes no sense.
(MAKE-PATHNAME :TYPE :UNSPECIFIC) ;not portable
;; #2: In this example, assume a Unix file system.
(PATHNAME-TYPE (PARSE-NAMESTRING "foo."))
=> ""
(PATHNAME-TYPE (PARSE-NAMESTRING "foo"))
=> :UNSPECIFIC
(PATHNAME-TYPE (MERGE-PATHNAMES (PARSE-NAMESTRING "foo")
(MAKE-PATHNAME :TYPE "BAR")))
=> :UNSPECIFIC
;; #3: In this example, assume an ITS file system.
(LET ((P (PARSE-NAMESTRING "FOO 32")))
(LIST (PATHNAME-TYPE P) (PATHNAME-VERSION P)))
=> (:UNSPECIFIC 32)
(LET ((P (PARSE-NAMESTRING "FOO TEXT")))
(LIST (PATHNAME-TYPE P) (PATHNAME-VERSION P)))
=> ("TEXT" :UNSPECIFIC)
(LET ((P (MERGE-PATHNAMES (PARSE-NAMESTRING "FOO 32")
(PARSE-NAMESTRING "FOO TEXT"))))
(LIST (PATHNAME-TYPE P) (PATHNAME-VERSION P)))
=> (:UNSPECIFIC 32)
;; Note: It is not the intent of this proposal to actually legislate
;; the canonical representation of Unix pathnames "foo." and "foo",
;; nor of ITS pathnames "FOO 32" and "FOO TEXT". That should probably
;; be done, but under separate cover. The above examples are intended
;; only to demonstrate how this proposal will permit the representation
;; of pathnames not usefully representable under CLtL.
Rationale:
This is, by necessity, current practice in some implementations
already.
Current Practice:
Symbolics Genera uses a file types and versions of :UNSPECIFIC on
Unix and ITS file systems, for example.
Cost to Implementors:
None. No change to any implementation is forced.
Some implementations which already do this are legitimized.
Some implementations which use a non-standard token other than
:UNSPECIFIC to implement this functionality would want to switch
to use :UNSPECIFIC so that portable programs could expect it.
Cost to Users:
Some programs which manipulate pathnames should be updated to expect
:UNSPECIFIC in the type fields in some situations.
Any program which doesn't already expect :UNSPECIFIC is already not really
portable, however, given that some implementations have been forced to
go beyond the standard in order to represent all possible pathnames.
Cost of Non-Adoption:
Some implementations would be unable to both represent all possible
pathnames in a rational way and at the same time to conform to the
standard. Such an inability would seriously jeopardize the usefulness
of Common Lisp in the design of serious programs.
Benefits:
Some programs involving pathnames would be more portable.
Aesthetics:
Sweeping a hairy situation under the rug doesn't make it go away.
This change makes things appear less simple, but since in reality
they were less simple, it is effectively a simplification of the
correspondence between the CL model and reality.
Discussion:
Pitman and Moon support PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN.
This feature existed (for types) in the Colander draft edition of
CLtL, but was removed for the Laser edition. The following text is
excerpted from the Colander edition, p259:
``??? Query: Is :unspecific really needed over and above nil?
``A component of a pathname can also be the keyword
:UNSPECIFIC. This means that the component has been explicitly
determined not to be there, as opposed to be missing. One way
this can occur is with generic pathnames, which refer not to
a file but to a whole family of files. The version, and usually
the type, of a generic pathname are :unspecific. Another way
:unspecific is used to represent components that are not simply
supported by a file system. When a pathname is converted to a
namestring, nil and :unspecific both cause the component not to
appear in the string. When merging, however, a nil value for
a component will be replaced with the default for that
component, while :unspecific will be left alone.''
"The stuff about generic pathnames in the discussion section
was brain damage and may have lead to the confusion that caused
:unspecific to be dropped from Common Lisp. Only the stuff about
components not supported by a file system makes sense."
∂12-Jan-89 1731 X3J13-mailer Issue: PACKAGE-FUNCTION-CONSISTENCY (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 17:31:09 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 JAN 89 17:20:59 PST
Date: 12 Jan 89 17:20 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: PACKAGE-FUNCTION-CONSISTENCY (Version 2)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890112-172059-1554@Xerox>
!
Issue: PACKAGE-FUNCTION-CONSISTENCY
References: 11.7 Package System Functions and Variables (pp182-188)
Category: CLARIFICATION/CHANGE
Edit history: 21-Oct-88, Version 1 by Pitman
12-Jan-89, Version 2 by Masinter (add MORE-PERMISSIVE option)
Problem Description:
CLtL is vague about whether either or both of package or package name
are permissible in some cases.
Proposal (PACKAGE-FUNCTION-CONSISTENCY:PERMISSIVE):
Clarify that it is permissible to pass either a package object
or a package name (symbol or string) in the following situations:
- the :USE argument to MAKE-PACKAGE or IN-PACKAGE
- the first argument to IN-PACKAGE, FIND-PACKAGE, and RENAME-PACKAGE
- the second argument to INTERN, FIND-SYMBOL, UNINTERN
- the second argument to EXPORT, UNEXPORT, IMPORT,
SHADOWING-IMPORT, and SHADOW
- the first argument (or a member of the list which is the first
argument) to USE-PACKAGE or UNUSE-PACKAGE.
- the PACKAGE argument to DO-SYMBOLS.
- the PACKAGE argument to DO-EXTERNAL-SYMBOLS.
- the PACKAGE argument to DO-ALL-SYMBOLS.
If FIND-PACKAGE is given a package object as an argument, it simply
returns it.
If IN-PACKAGE is given a package object as an argument, that package
is selected. It is an error if, when a package object is given as a
first argument to IN-PACKAGE, a :USE list is explicitly specified and
does not exactly match the package or :NICKNAMES is explicitly supplied
and does not exactly match the package.
Clarify that the functions PACKAGE-NAME, PACKAGE-NICKNAMES,
PACKAGE-USE-LIST, and PACKAGE-USED-BY-LIST are (at least conceptually)
accessors to package data structures and permit only package objects
as arguments.
Clarify that the function MAKE-PACKAGE permits only a package name
as an argument since it does not make sense to create an existing
package.
Clarify that package nicknames must always be expressed as package
names (symbols or strings) and may never be actual package objects.
Proposal: (PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE)
In addition, require that PACKAGE-NAME, PACKAGE-NICKNAMES,
PACKAGE-USE-LIST, and PACKAGE-USED-BY-LIST to accept names,
too.
Examples:
(INTERN "FOO" "KEYWORD") => :FOO
(DEFVAR *FOO-PACKAGE* (MAKE-PACKAGE "FOO"))
(RENAME-PACKAGE "FOO" "FOO0")
(PACKAGE-NAME *FOO-PACKAGE*) => "FOO0"
Under MORE-PERMISSIVE,
(PACKAGE-NAME "SYS") might return "SYSTEM".
Rationale:
This makes things more consistent.
MORE-PERMISSIVE adds a generally useful capability.
Current Practice:
Symbolics Genera & Lucid permits strings as package names.
Symbolics Cloe does not permit strings as package names.
In Lucid FIND-PACKAGE and IN-PACKAGE require names.
Cost to Implementors:
Small. A tiny bit more for MORE-PERMISSIVE.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Implementations would continue to vary gratuitously, leaving a potential
for portability problems.
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
This makes things more regular, and so presumably more aesthetic.
Discussion:
Pitman ran across this problem while trying to port Macsyma to various
implementations. Discussion with other maintainers of portable programs
shows this is a common source of aggravation in portable code.
Since the pathname accessors all take namestrings or streams, one might
easily argue that it would be more consistent for PACKAGE-NAME,
PACKAGE-NICKNAMES, etc. to also take arguments of package names. After
all,
(PACKAGE-NAME "FOO") => "FOO"
is no stranger than
(NAMESTRING "JOE:fred.lisp") => "JOE:fred.lisp".
It would be possible to say that MAKE-PACKAGE took package objects as
arguments and just returned that package. That might have limited
usefulness on rare occassions, but mostly seemed too far out in left
field to bother suggesting it.
∂12-Jan-89 1836 @Score.Stanford.EDU:allison@shasta.stanford.edu Re: Broadcast of courses on SUNet
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Jan 89 18:36:43 PST
Received: from shasta.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 12 Jan 89 17:57:15-PST
Received: by shasta.stanford.edu; Thu, 12 Jan 89 17:54:50 PST
Date: Thu, 12 Jan 89 17:54:50 PST
From: Dennis Allison <allison@shasta.stanford.edu>
Subject: Re: Broadcast of courses on SUNet
To: csd@score.stanford.edu, eyal@coyote.stanford.edu,
faculty@score.stanford.edu
Cc: tajnai@score.stanford.edu
My immediate concern is EE380, the Computer Systems Lab Colloquium. The
class format is simple: invited speakers give a talk on some aspect of
computer systems every Wednesday afternoon. The class is videotaped, broadcast
on the instructional TV network, and available for live viewing. Over the
years there has been a substantial shift towards more video viewing and less
live participation. For those students who could attend live but choose the
video route, I think there is a loss of immediacy and excitement. For the
speaker it is sometimes embarassing because the live audience is so much smaller
than the enrollment. Sometime a speaker must conclude to himself that his
topic must be unpopular because so few folks turned up for the live show.
Classes are as much a social experience as transfer of information. The
video option changes the class structure and changes the social interaction.
In the case of EE380, I think the video option is detrimental to the
social goals of the course. I would oppose expanding the distribution of the
video to people who could easily attend in person on those grounds.
∂12-Jan-89 1928 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU re: Broadcast of courses on SUNet
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Jan 89 19:24:23 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 12 Jan 89 19:22:27-PST
Message-ID: <v#a2N@SAIL.Stanford.EDU>
Date: 12 Jan 89 1923 PST
From: John McCarthy <JMC@SAIL.Stanford.EDU>
Subject: re: Broadcast of courses on SUNet
To: allison@SHASTA.STANFORD.EDU, csd@SCORE.STANFORD.EDU, eyal@COYOTE.STANFORD.EDU,
faculty@SCORE.STANFORD.EDU
CC: tajnai@SCORE.STANFORD.EDU
[In reply to message from allison@shasta.stanford.edu sent Thu, 12 Jan 89 17:54:50 PST.]
I have no objection to having my course broadcast and am somewhat dismayed
at Dennis Allison's objections. In general I oppose the paternalism of
restricting people's options ``for their own good'' or just to put on a
better show. It would require very strong evidence of actual harm to
convince me.
∂12-Jan-89 2125 @Score.Stanford.EDU:dill@amadeus.Stanford.EDU re: Broadcast of courses on SUNet
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Jan 89 21:25:20 PST
Received: from amadeus.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 12 Jan 89 21:22:13-PST
Received: by amadeus.Stanford.EDU (5.59/inc-1.0)
id AA06865; Thu, 12 Jan 89 21:22:33 PDT
Date: Thu, 12 Jan 89 21:22:33 PDT
From: dill@amadeus.Stanford.EDU (David Dill)
Message-Id: <8901130522.AA06865@amadeus.Stanford.EDU>
To: JMC@SAIL.Stanford.EDU, allison@SHASTA.STANFORD.EDU, csd@SCORE.STANFORD.EDU,
eyal@COYOTE.STANFORD.EDU, faculty@SCORE.STANFORD.EDU
Subject: re: Broadcast of courses on SUNet
Cc: tajnai@SCORE.STANFORD.EDU
I vehemently oppose live on-campus broadcasts of my lectures. It seems
to me that the reasonable thing is for SITN to respect the preferences
of the individual lecturers. If my classes were broadcast last year
on campus, no one asked me about it, or even told me about it. I
would resent this if it were true.
∂12-Jan-89 2245 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: Broadcast of courses on SUNet
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Jan 89 22:45:19 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 12 Jan 89 22:42:54-PST
Message-ID: <v#cnV@SAIL.Stanford.EDU>
Date: 12 Jan 89 2243 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Re: Broadcast of courses on SUNet
To: faculty@SCORE.STANFORD.EDU, csd@SCORE.STANFORD.EDU, eyal@COYOTE.STANFORD.EDU
I have a problem with students videotaping my classes, or having their own
videotape copies of my lectures. I think Stanford may have a licensing
problem there too. I think that if people can listen to me live, and they
are on campus, they should come to class. If they can't listen to me
live, I don't want them having their own videotapes of my lectures; they
are available to be viewed in the library.
Arthur
∂13-Jan-89 0102 @Score.Stanford.EDU:eaf@sumex-aim.stanford.edu Re: Broadcast of courses on SUNet
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Jan 89 01:01:55 PST
Received: from sumex-aim.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 13 Jan 89 00:59:14-PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA09720; Fri, 13 Jan 89 00:58:05 PST
Date: Fri, 13 Jan 1989 0:58:05 PST
From: Edward A. Feigenbaum <eaf@sumex-aim.stanford.edu>
To: Dennis Allison <allison@shasta.stanford.edu>
Cc: csd@score.stanford.edu, eyal@coyote.stanford.edu,
faculty@score.stanford.edu, tajnai@score.stanford.edu
Subject: Re: Broadcast of courses on SUNet
In-Reply-To: Your message of Thu, 12 Jan 89 17:54:50 PST
Message-Id: <CMM.0.88.600685085.eaf@sumex-aim.stanford.edu>
I've had the same experience that Dennis reports, and would rather have the
students in the lecture room.
Ed F.
∂13-Jan-89 0833 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Tuesday's Facutly Lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Jan 89 08:33:14 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 13 Jan 89 08:30:50-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA08726; Fri, 13 Jan 89 08:31:32 PDT
Date: Fri, 13 Jan 1989 8:31:19 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, bureaucrats@score
Subject: Tuesday's Facutly Lunch
Message-Id: <CMM.0.87.600712279.chandler@polya.stanford.edu>
Don't forget to mark your calendar for the next Faculty Lunch...Tuesday, 1/17
at 12:15 in MJH-146. Ed Feigenbaum, Bob Floyd and Mike Genesereth will lead
a discussion about how the Stanford CS Department ought to train PhD
students. See you there!
∂13-Jan-89 0851 @Score.Stanford.EDU:RPG@SAIL.Stanford.EDU Broadcast of courses on SUNet
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Jan 89 08:51:03 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 13 Jan 89 08:48:34-PST
Message-ID: <$$7$L@SAIL.Stanford.EDU>
Date: 13 Jan 89 0849 PST
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Subject: Broadcast of courses on SUNet
To: faculty@SCORE.STANFORD.EDU
Since someone vehemently opposes broadcast, let me put in my opinion that
I like broadcast situations. I haven't had to teach courses that were
broadcast, but I have given many lectures that way. As with haiku, I find
that a restricted medium causes me to think more carefully about what I
will say and how I say it. I think that students in the live audience in
overhead camera situations might suffer a little, but I think no one else
does. It takes some concentration to be able to look at the monitors to
make sure the camera is looking at the right things. The fact that I might
be taped by students doesn't bother me except insofar as I hope they are
able to have whatever understanding problems they have cleared up by
multiple view.
-rpg-
∂13-Jan-89 0900 @Score.Stanford.EDU:cleron@polya.Stanford.EDU Re: Broadcast of courses on SUNet
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Jan 89 09:00:40 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 13 Jan 89 08:53:29-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA09598; Fri, 13 Jan 89 08:53:59 PDT
Date: Fri, 13 Jan 1989 8:53:58 PST
Sender: "Michael A. Cleron" <cleron@polya.stanford.edu>
From: "Michael A. Cleron" <cleron@polya.stanford.edu>
To: Eyal Mozes <eyal@coyote.stanford.edu>
Cc: csd@score.Stanford.EDU, faculty@score.Stanford.EDU
Subject: Re: Broadcast of courses on SUNet
In-Reply-To: Your message of Thu, 12 Jan 89 16:41:08 PST
Message-Id: <CMM.0.87.600713638.cleron@polya.stanford.edu>
Having taught several classes on TV, I prefer my students to watch my
lectures live. I think they learn more, and I don't like talking to
empty chairs. However, back when I was a student, I had an alter-ego
named Captain Video who haunted the math library waiting for VCR's to
become free. This was usually pretty unpleasant. I would have been
deliriously happy if I could have made my own taped copies of the
lectures I missed.
We ought to remember that we teach classes for the benefit of our
students; they do not exist to serve our needs. By now, they should
be able to determine their own study habits. We should not force them
to attend classes live just because we think it is good for them. The
key, of course, is to make lectures sufficiently interesting that
students *want* to participate live.
Local blackouts of televised courses is a bad idea.
∂13-Jan-89 0909 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: Broadcast of courses on SUNet
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Jan 89 09:09:14 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 13 Jan 89 09:01:08-PST
Message-ID: <D$7lr@SAIL.Stanford.EDU>
Date: 13 Jan 89 0902 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Re: Broadcast of courses on SUNet
To: RPG@SAIL.Stanford.EDU
CC: faculty@SCORE.STANFORD.EDU
I taught on TV for the first time this fall quarter. I made an effort to
ensure that the camera was pointing where I wanted, often by giving
appropriate instructions to the camera operator. I happen to prefer using
the blackboard to using the desk.
I like having students in the classroom and don't want to encourage
students to watch it remotely (except with talkback). I get a fair amount
of feedback from expressions on students' faces and from their questions.
When I videotaped a few lectures in advance, there were only a few
students and I realized how important their physical presence is for my
sense of timing in covering the lecture (how fast to go, when to pause,
etc.). I don't like lecturing to an empty classroom and believe I do a
better job for the students when I can get adequate visual feedback from
the students.
Arthur
∂13-Jan-89 0918 TAJNAI@Score.Stanford.EDU Broadcast of courses on SUNet
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Jan 89 09:17:56 PST
Date: Fri 13 Jan 89 09:04:41-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Broadcast of courses on SUNet
To: faculty@Score.Stanford.EDU
cc: allison@Sierra.Stanford.EDU, na.adp@forsythe.Stanford.EDU
Message-ID: <12462250155.11.TAJNAI@Score.Stanford.EDU>
I believe that seminars and courses that feature visiting speakers --
particularly industry speakers -- should be considered separately from
courses taught by Stanford people.
Visiting industrial speakers sign an agreement allowing their talk to
be broadcast on SITN. SITN has an agreement with its member companies that
if they tape a course, the tape will be destroyed within a stated period
of time.
Frequently, the visitors cannot sign the Computer Forum Agreement (release)
without first getting approval from company lawyers. And occasionally, they
have to decline because approval is not forthcoming.
If the broadcast is over SUNet and lectures can be taped randomly
with no controls, then we will run into the problem of speakers refusing to
come, or at the last minute refusing to speak. Not to tell them that the
lecture is being broadcast over SUNet would be a breach of ethics.
Carolyn
-------
∂13-Jan-89 0928 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Tuesday's Faculty Lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Jan 89 09:28:02 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 13 Jan 89 09:15:37-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA10698; Fri, 13 Jan 89 09:16:16 PDT
Date: Fri, 13 Jan 1989 9:16:03 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, bureaucrats@score
Subject: Tuesday's Faculty Lunch
Message-Id: <CMM.0.87.600714963.chandler@polya.stanford.edu>
To correct my earlier message, the Feigenbaum/Floyd/Genesereth discussion is
scheduled for 1/24. January 17th topic Bill Yundt, SDtanford Networking and
Mike Roberts (Educom) talking about "Networks of the Future". Sorry for the
mixup.
∂13-Jan-89 1013 @Score.Stanford.EDU:tom@polya.Stanford.EDU SITN
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Jan 89 10:12:54 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 13 Jan 89 10:08:55-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA13301; Fri, 13 Jan 89 10:09:37 PDT
Date: Fri, 13 Jan 89 10:09:37 PDT
From: Tom Dienstbier <tom@polya.Stanford.EDU>
Message-Id: <8901131809.AA13301@polya.Stanford.EDU>
To: faculty@score
Subject: SITN
My two cents worth from a different angle. About two years ago CSDCF in-
stalled a broadband system in Margaret Jacks for mainly one reason.
If individuals wanted to they could view the Stanford televised classes
in Jacks. A couple of TV's were installed, student lounge and Nils
conference room. About the time that this was installed SITN stopped
transmitting to the campus buildings. I belive though SITN was still
broadcasting to the dorms, student housing. The reason, as I was told, that
transmission was stopped to Jacks and other campus buildings was that a
questionaire was sent around to faculty asking if they wanted their courses
transmitted to campus buildings. Only a couple faculty responded. Their
responce was that they did not want their televised classes going
to buildings like Jacks for fear that the class attendance would drop off.
Thus a decision was made based on the limited responce to the questionaire.
I for one would like to have the option to be able to view some of the classes.
We do however have about half a dozen other channels to view, some of them
even educational currently in Jacks.
Tom
∂13-Jan-89 1029 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: SITN
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Jan 89 10:29:33 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 13 Jan 89 10:19:58-PST
Message-ID: <1r$95h@SAIL.Stanford.EDU>
Date: 13 Jan 89 1020 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Re: SITN
To: tom@POLYA.STANFORD.EDU
CC: faculty@SCORE.STANFORD.EDU
Did the same questionnaire ask whether the faculty wanted their lectures
to go to dorms and residences? I'm not sure people would prefer allowing
students to watch the classes at home and yet not allow viewing in campus
buildings. In fact, my opinions tend toward the opposite.
Arthur
∂13-Jan-89 1043 @Score.Stanford.EDU:bhayes@polya.Stanford.EDU faculty mailing list
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Jan 89 10:41:10 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 13 Jan 89 10:22:54-PST
Received: from LOCALHOST by polya.Stanford.EDU (5.59/25-eef) id AA14275; Fri, 13 Jan 89 10:23:36 PDT
Message-Id: <8901131823.AA14275@polya.Stanford.EDU>
To: faculty@score
Subject: faculty mailing list
Date: Fri, 13 Jan 89 10:23:34 -0800
From: bhayes@polya.Stanford.EDU
At Tuesday's faculty meeting I mentioned that the bureaucrats were
included in the faculty mailing list, and was surprised that many
people didn't know this. It also came up that there are many other
names on the faculty mailing list that are surprising.
In any case, I received the permission of the faculty to repost
messages to appropriate bboards, and remail to interested students.
Just thought those of you not able to be present should be informed.
∂13-Jan-89 1143 @Score.Stanford.EDU:eyal@coyote.stanford.edu Re: broadcast of courses on SUNet
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Jan 89 11:43:51 PST
Received: from coyote.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 13 Jan 89 11:39:37-PST
Received: by coyote.stanford.edu; Fri, 13 Jan 89 11:36:04 PST
Date: Fri, 13 Jan 89 11:36:04 PST
From: Eyal Mozes <eyal@coyote.stanford.edu>
Subject: Re: broadcast of courses on SUNet
To: csd@score.Stanford.EDU, faculty@score.Stanford.EDU
My message about broadcast of courses raised several responses, both
pro and con. As far as I can see, two arguments were raised against the
broadcast of courses:
1. Some professors say it is important to them that students attend
their lectures live, rather than watch tapes. I see two answers to this
objection:
a. Even without the broadcast on SUNet, it is possible for students to
watch tapes of the lectures rather than attend them. Only, for that
they must stand in line for a video machine in the library. As long as
watching tapes is possible, I see no point in deliberately making it
less convenient.
b. Courses have been broadcast on SUNet in the past, and most students
still attended the live lectures. In the four televised courses I
attended last quarter (all of which were broadcast on SUNet), the
classroom was always nearly full. So, if anyone is afraid of having to
talk to an empty classroom, we can see that this does not, in fact,
happen. Personally, I would always rather attend a live lecture than
watch it on tape; but, occasionally, I can't attend the lecture, and
then I'd much rather watch it at home than stand in line at the
library. Experience shows that most students' attitude is the same.
2. A concern was also raised about students keeping tapes of lectures.
I don't believe this has actually happened; I know that whenever I
taped a lecture, I watched it once (or, if the material was very
difficult, twice) and then erased it; I'm sure that's what other
students did, too. I can see that Carolyn Tajnai's concern about
visiting lecturers is valid; but, as she said, this situation is
different from lectures by Stanford faculty.
Since opinion seems divided on the subject, maybe the solution is to
have each professor of a televised course decide whether his course
will be broadcast. Anyway, a decision on the subject has to be made by
the Engineering School (or maybe by the Computer Science Department
independently), and the current situation (not broadcasting any of the
courses) is definitely not right. So, as I said, I ask all faculty who
teach televised courses to inform the Engineering School and SUNet of
their opinion.
Eyal Mozes (eyal@coyote)
∂13-Jan-89 1609 @Score.Stanford.EDU:ungar@self Re: SITN
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Jan 89 16:09:10 PST
Received: from self by SCORE.STANFORD.EDU with TCP; Fri 13 Jan 89 16:06:42-PST
Received: by self (4.0/inc-1.0)
id AA04087; Fri, 13 Jan 89 16:05:03 PST
Date: Fri, 13 Jan 89 16:05:03 PST
From: ungar@self.stanford.edu (David Ungar)
Message-Id: <8901140005.AA04087@self>
To: ARK@SAIL.Stanford.EDU, tom@POLYA.STANFORD.EDU
Subject: Re: SITN
Cc: faculty@SCORE.STANFORD.EDU
This strikes me as a very tough question.
There is no doubt in my mind that we cheat students by allowing
them to watch something on TV when they could be there in person.
On the other hand, better that they watch on TV than they miss it altogether.
David
∂13-Jan-89 1629 @Score.Stanford.EDU:bhayes@polya.Stanford.EDU SITN metadiscussion
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Jan 89 16:29:51 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 13 Jan 89 16:26:55-PST
Received: from LOCALHOST by polya.Stanford.EDU (5.59/25-eef) id AA10442; Fri, 13 Jan 89 16:27:29 PDT
Message-Id: <8901140027.AA10442@polya.Stanford.EDU>
To: csd-bboard@polya.Stanford.EDU, faculty@polya.Stanford.EDU
Subject: SITN metadiscussion
Date: Fri, 13 Jan 89 16:27:25 -0800
From: bhayes@polya.Stanford.EDU
"What we have here is failure to communicate."
There is a very lively discussion on the pros and cons of various forms
of televised classes going on in the faculty mailing list. Students
following this in the bboard (csd-bboard@polya) are replying by posting
on just that bboard. As far as I know, very few faculty members read
that bboard, and so will never even know that students have an opinion
on this subject.
Should students replying to messages cc the faculty mailing list?
Should faculty read the bboard? I'd like to know that ALL the people
interested in the subject were hearing each other.
∂13-Jan-89 2326 @Score.Stanford.EDU:cheriton@Pescadero.Stanford.EDU More on broadcast of courses
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Jan 89 23:26:43 PST
Received: from Pescadero.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 13 Jan 89 23:24:03-PST
Received: by Pescadero.Stanford.EDU (5.59/25-eef) id AA01294; Fri, 13 Jan 89 23:26:55 PDT
Date: Fri, 13 Jan 89 23:26:55 PDT
From: David Cheriton <cheriton@Pescadero.Stanford.EDU>
Message-Id: <8901140726.AA01294@Pescadero.Stanford.EDU>
To: faculty@score
Subject: More on broadcast of courses
It seems to me that this issue is a non-trivial one. The university
is clearly motivated to tape/broadcast our classes to make money.
To date, I've been willing to go along with this, being a good guy,
even though it definitely involved more effort and students that if
I had refused. I've always felt it was unfortunate that there was
basically no recognition given to those of us making this extra effort,
or any consideration given to class size in general.
However, I too have been bothered by having a relatively large class in
enrolment with far fewer in physical attendance. So, I'm not anxious
to encourage this direction. I also just turned down an SITN request
to give a former student a personal copy of one of my lectures.
The major issues I have in mind are:
1) Who owns the what rights on these tapes? Can the university continute
to offer a course by a faculty member using tapes of his lectures
after he has left or been terminated?
2) Can a faculty member offer a course by simply replaying lectures from
a previous year, providing he manages TAs to mark assignements, etc.
and still satisfying his teaching load requirements with such a course.
3) If the courses are broadcast, who is allowed to watch? Can a student
charge others to sit in his dorm room and watch these lectures.
Can he offer this for free? Afterall, some people pay good money for
right to attend our lectures.
In general, musicians and other performers exercise significant control over
the rights to their performances. I think we should be able to have the
same rights and control. Does anyone know the universities current position
on this. The fac. handbook seems suitably ambiguous on any electronic
version of course material (or unsuitably interpretable by the adminstration
I should say). My perception is that this is a good time (if not too late
) to establish that we have performer rights over the tapes.
In particular, the university is paying per performance, and does not
have replay rights without consent.
David C.
∂13-Jan-89 2328 barwise@russell.Stanford.EDU Interns
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Jan 89 23:28:19 PST
Received: from localhost by russell.Stanford.EDU (4.0/inc-1.0)
id AA09920; Fri, 13 Jan 89 23:28:27 PST
Message-Id: <8901140728.AA09920@russell.Stanford.EDU>
To: ssp-faculty@russell.Stanford.EDU
Subject: Interns
Date: Fri, 13 Jan 89 23:28:25 PST
From: Jon Barwise <barwise@russell.Stanford.EDU>
Could you answer the following questionaire:
I definitely plan to announce a project that an SSP student might
particpate in this summer, with 1/2 funds from csli.
I hope to, if I can find the funds.
I would like to, but know that there are no funds available to me for
this sort of thing.
I am not interested in the Intern Program this summer.
Thanks,
Jon
∂14-Jan-89 0006 @Score.Stanford.EDU:allison@shasta.stanford.edu More on the TV question
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Jan 89 00:06:01 PST
Received: from shasta.stanford.edu by SCORE.STANFORD.EDU with TCP; Sat 14 Jan 89 00:03:36-PST
Received: by shasta.stanford.edu; Sat, 14 Jan 89 00:01:11 PST
Date: Sat, 14 Jan 89 00:01:11 PST
From: Dennis Allison <allison@shasta.stanford.edu>
Subject: More on the TV question
To: faculty@score.stanford.edu
If we are going to give video classes, shouldn't we try to use
the medium effectively rather than simply capturing a talking head
and the visual aids that go with a modified form of the traditional
lecture. We should have music, special effects, good professional
graphics, and all the other production values one associated with
professinal video production.
∂14-Jan-89 0037 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU re: More on the TV question
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Jan 89 00:37:01 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sat 14 Jan 89 00:34:39-PST
Message-ID: <L$PQs@SAIL.Stanford.EDU>
Date: 14 Jan 89 0035 PST
From: John McCarthy <JMC@SAIL.Stanford.EDU>
Subject: re: More on the TV question
To: allison@SHASTA.STANFORD.EDU, faculty@SCORE.STANFORD.EDU,
csd@SCORE.STANFORD.EDU
[In reply to message from allison@shasta.stanford.edu sent Sat, 14 Jan 89 00:01:11 PST.]
Here's one data point on doing TV classes in a professional way.
In the late 1950s and early 1960s, Jerrold Zacharias of M.I.T.
did the widely praised high school level lectures on physics in a
fully professional way. The cost was about $100,000 per lecture
paid for by post Sputnik educational money. It was his major
activity for several years. The School Mathematics Study Group
was headquartered at Stanford and spent a number of years
preparing filmed high school math courses. If some of us
undertook to produce salable TV lecture courses, the costs would
be similar, and the lecturer preparation and rehearsal time would
be enormous. It might be better for professors to prepare the
material and have actors actually give the lectures.
This matter is entirely orthogonal to allowing students listen to
lectures remotely and tape them. I don't believe the latter
could result in a salable product or even detract from the market
for professionally prepared lecture courses.
Should Department decides to do this, include me out. Those of
us who just continue doing computer science might make a given
video lecture course obsolete before it is even finished.
∂14-Jan-89 0803 @Score.Stanford.EDU:CAB@SAIL.Stanford.EDU Professional TV lectures
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Jan 89 08:02:57 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sat 14 Jan 89 08:00:47-PST
Message-ID: <4$Vjb@SAIL.Stanford.EDU>
Date: 14 Jan 89 0752 PST
From: Chuck Bigelow <CAB@SAIL.Stanford.EDU>
Subject: Professional TV lectures
To: allison@SHASTA.STANFORD.EDU
CC: faculty@SCORE.STANFORD.EDU
This opens up "insanely great" possibilities:
"Algorithms of Fortune", starring Don "DEK" Knuth and Vanna White!
"Miami Systems", starring Dave Cheriton and Don Johnson
"Artificial Intelligence, Natural Curls" [fill in your favorites]
and, of course, along with the "lectures" we can have that other
great, uplifting contribution by television to modern culture -
COMMERCIALS!
Just imagine what some really slick commercials could do for
the Computer Forum!
Selling computer science like soap, deodorant, and Isuzus!
(apologies to those whose names were mentioned without permission,
and for all the exclamation points)
∂14-Jan-89 0935 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu mailing lists
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Jan 89 09:35:20 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Sat 14 Jan 89 09:33:12-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA02573; Sat, 14 Jan 89 09:33:01 PDT
Date: Sat, 14 Jan 89 09:33:01 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8901141733.AA02573@Tenaya.stanford.edu>
To: faculty@score
Subject: mailing lists
This note is a reminder that when one sends a msg to "faculty@score,"
it goes to faculty plus student bureaucrats plus senior staff plus
research associates. I mention this because the student bureaucrats
sometimes (at their discretion) forward to the students msgs that
come to the bureaucrats via "faculty@score" (and that's fine with me).
Although one should never work under the illusion that e-mail is
private, sometimes the lists "tenured@score" and "ac@score" (the
latter is academic council) are the appropriate ones to use.
-Nils
∂14-Jan-89 0939 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu space in mjh
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Jan 89 09:39:13 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Sat 14 Jan 89 09:35:55-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA02576; Sat, 14 Jan 89 09:35:46 PDT
Date: Sat, 14 Jan 89 09:35:46 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8901141735.AA02576@Tenaya.stanford.edu>
To: faculty@score
Subject: space in mjh
George Wheaton, Yvette Sloan, and I will soon be meeting to review the
space situation in MJH. In summary, there is NO space for visitors
and/or others for next year in MJH that have not specifically been
approved and are known to us already. Faculty additions and previous
commitments to visitors will fill us up to the top! It looks like
we will be in this tight situation until the new building is
finished.
-Nils
∂14-Jan-89 1147 @Score.Stanford.EDU:dill@amadeus.Stanford.EDU TV
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Jan 89 11:47:48 PST
Received: from amadeus.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sat 14 Jan 89 11:45:30-PST
Received: by amadeus.Stanford.EDU (5.59/inc-1.0)
id AA09031; Sat, 14 Jan 89 11:46:24 PDT
Date: Sat, 14 Jan 89 11:46:24 PDT
From: dill@amadeus.Stanford.EDU (David Dill)
Message-Id: <8901141946.AA09031@amadeus.Stanford.EDU>
To: faculty@score.stanford.edu
Subject: TV
Unlike JMC, I teach (almost) every quarter. I teach 100-level classes
with many undergraduates, who do NOT always know what is good for them.
Every class I teach is televised, and every one has had more than 50
graded students at the end and sometimes more than 100.
I do not object to the televised classes, although my job would be easier
if they were not televised. Correct me if I'm wrong, but I think it's
unusual for university professors to have to teach to TV cameras.
I believe that it is beneficial for students to attend lectures. First,
it makes the lecture more interesting to everyone. I ask a lot of questions
of the students during the lecture. I think that the interaction helps
my enthusiasm, and raises a lot of points that I would not normally
bring up. Second, I think the most important factor in making a lecture
effective is student involvement -- the students should be actively
thinking ahead of what I am saying. Passive TV viewing is in total
opposition to this.
I don't have documented scientific evidence to support these feelings
(nor should I need it). They are based on my teaching experience
(which is rather limited) and, more importantly, on my own experiences
as a student.
If I have to show up for lectures at a particular time and place
I don't see why the students should be exempted from the same duty. If
TV viewing is so effective, why do we have to give the same lectures
repeatedly? Perhaps instead of lecturing I should replay videotapes
from previous quarters. Would Stanford pay my salary if I did this?
By the way, is it unreasonable to expect that people would refrain
from making ad hominem attacks on their colleagues on this mailing
list?
∂14-Jan-89 2005 @Score.Stanford.EDU:ungar@self Re: TV
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Jan 89 20:05:43 PST
Received: from self by SCORE.STANFORD.EDU with TCP; Sat 14 Jan 89 20:03:32-PST
Received: by self (4.0/inc-1.0)
id AA04399; Sat, 14 Jan 89 20:01:51 PST
Date: Sat, 14 Jan 89 20:01:51 PST
From: ungar@self.stanford.edu (David Ungar)
Message-Id: <8901150401.AA04399@self>
To: dill@amadeus.Stanford.EDU, faculty@score.stanford.edu
Subject: Re: TV
How about making ad homonym attacks?
David
PS: Thanks, Dave D., for explaining why students who don't attend in person
lose out.
∂15-Jan-89 1203 TAJNAI@Score.Stanford.EDU [Tracy Larrabee <larrabee@polya.Stanford.EDU>: Re: COMPUTER FORUM ---POSTER SESSION -- REVISED DEADLINE ]
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Jan 89 12:03:29 PST
Date: Sun 15 Jan 89 12:01:01-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: [Tracy Larrabee <larrabee@polya.Stanford.EDU>: Re: COMPUTER FORUM ---POSTER SESSION -- REVISED DEADLINE ]
To: faculty@Score.Stanford.EDU, hiller@Score.Stanford.EDU
Message-ID: <12462806542.9.TAJNAI@Score.Stanford.EDU>
Prof. De Micheli has received no commitments from students to participate
in the Poster Session. I knew that Tracy Larrabee was enthusiastic about
the Poster Session last year, and I asked her to send a message to the
students. The following is the result, and I thought you should all read it.
I hope you will encourage your students to participate in the Poster Session.
Carolyn
---------------
Return-Path: <larrabee@polya.Stanford.EDU>
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sat 14 Jan 89 23:24:14-PST
Received: from LOCALHOST by polya.Stanford.EDU (5.59/25-eef) id AA21887; Sat, 14 Jan 89 23:24:52 PDT
Message-Id: <8901150724.AA21887@polya.Stanford.EDU>
To: nanni@galileo.stanford.edu (Giovanni De Micheli)
Cc: csl-students@sierra.Stanford.EDU, students@score.Stanford.EDU,
tajnai@score.Stanford.EDU, larrabee@polya.Stanford.EDU
Subject: Re: COMPUTER FORUM ---POSTER SESSION -- REVISED DEADLINE
In-Reply-To: Your message of Fri, 13 Jan 89 16:37:12 -0800.
<8901140037.AA22043@galileo.Stanford.EDU>
Date: Sat, 14 Jan 89 23:24:51 -0800
From: Tracy Larrabee <larrabee@polya.Stanford.EDU>
This year I am giving a forum talk, but last year I presented a poster. I
wanted to make sure that those students who vaguely considered presenting a
poster but decided their work wasn't ready, or it was too much work, or it
would keep them from doing the research they needed to finish so that they
could give a Forum talk next year. . . well, they should reconsider.
I actually have some results now, but last year I was just beginning to get
anything. I had an approach to explain, but I really didn't have any proof
that what I was doing was going to pan out. I was really nervous about the
poster session, but Carolyn Tajnai convinced me that it would be a good
warm up for more formal presentations of my work and that it would just
generally be "a good idea." (Thank you, Carolyn.)
Of course, I made my poster at the last minute, and of course it had a couple
of glaring (to me) mistakes in it when I walked into the session. But when
the poster session started, it didn't really matter. I stopped thinking about
any errors on my poster because I was too busy talking to people. I even
forgot to be nervous because it wasn't really a formal presentation and I
was just talking with some people about my ideas (and their ideas). I had
a good time, I made some good contacts, and I kept my enthusiasm long
enough to have a period of productivity unrivaled in my post-qual Stanford
career.
I think it was a good deal.
-------
∂15-Jan-89 1321 @Score.Stanford.EDU:coraki!pratt@Sun.COM Occasional summaries of student opinion
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Jan 89 13:21:07 PST
Received: from Sun.COM by SCORE.STANFORD.EDU with TCP; Sun 15 Jan 89 13:18:46-PST
Received: from sun.Sun.COM (sun-bb.sun.com) by Sun.COM (4.1/SMI-4.0)
id AA24050; Sun, 15 Jan 89 13:21:32 PST
Received: from coraki.UUCP by sun.Sun.COM (4.0/SMI-4.0)
id AA25415; Sun, 15 Jan 89 13:18:48 PST
Received: by (4.0/SMI-4.0Beta)
id AA24919; Sun, 15 Jan 89 11:28:28 PST
Date: Sun, 15 Jan 89 11:28:28 PST
From: Vaughan Pratt <coraki!pratt@Sun.COM>
Message-Id: <8901151928.AA24919@>
To: faculty@score.stanford.edu
Subject: Occasional summaries of student opinion
I for one would appreciate seeing on this mailing list an occasional
summary of recent trends in student opinion. How about if the student
bureaucrats take on the responsibility for this? An appropriate
startup strategy would be for them to do it themselves in the beginning
to debug the process, then delegate the work if it gets too
burdensome.
-v
∂15-Jan-89 1326 @Score.Stanford.EDU:coraki!pratt@Sun.COM Re: SITN
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Jan 89 13:26:30 PST
Received: from Sun.COM by SCORE.STANFORD.EDU with TCP; Sun 15 Jan 89 13:24:17-PST
Received: from sun.Sun.COM (sun-bb.sun.com) by Sun.COM (4.1/SMI-4.0)
id AA24038; Sun, 15 Jan 89 13:21:25 PST
Received: from coraki.UUCP by sun.Sun.COM (4.0/SMI-4.0)
id AA25427; Sun, 15 Jan 89 13:18:58 PST
From: coraki!pratt@Sun.COM
Received: from localhost by (4.0/SMI-4.0Beta)
id AA25092; Sun, 15 Jan 89 13:01:09 PST
Message-Id: <8901152101.AA25092@>
To: John McCarthy <JMC@sail.stanford.edu>
Cc: faculty@score.stanford.edu, csd@score.stanford.edu
Subject: Re: SITN
In-Reply-To: Your message of 13 Jan 89 1656 PST.
<10$ti7@SAIL.Stanford.EDU>
Date: 15 Jan 89 13:01:07 PST (Sun)
I don't understand any sentence beginning "There is no doubt in my
mind that we cheat students by allowing them to ...". Could you
explain the general principle of such sentences?
How about the principle that learning requires discipline, some of
which may need to come from the teacher? Students typically don't feel
cheated at the time, the reaction can be delayed by years.
-v
∂15-Jan-89 1336 @Score.Stanford.EDU:gio@sumex-aim.stanford.edu TV and lectures, my vote
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Jan 89 13:36:49 PST
Received: from sumex-aim.stanford.edu by SCORE.STANFORD.EDU with TCP; Sun 15 Jan 89 13:34:35-PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA05942; Sun, 15 Jan 89 13:35:46 PST
Date: Sun, 15 Jan 1989 13:35:45 PST
From: Gio Wiederhold <gio@sumex-aim.stanford.edu>
To: faculty@score.stanford.edu
Subject: TV and lectures, my vote
Message-Id: <CMM.0.88.600903345.gio@sumex-aim.stanford.edu>
I am quite willing to have stdents see them anywhere. As long as some
students show up live that is good enough for me. Any students/enterpreneurs
foolish enough to record them for posterity underestimate the pace of
technology and the interaction of readings and homework in a course.
It's hard enough to keep books up-to-date. I do refuse to put research
seminars, where interaction is desired, on TV. It is my right to cooperate
or not. fin.
Gio
∂16-Jan-89 1103 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu CSD Retreat
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Jan 89 11:03:38 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 16 Jan 89 10:41:00-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA03844; Mon, 16 Jan 89 10:40:40 PDT
Date: Mon, 16 Jan 89 10:40:40 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8901161840.AA03844@Tenaya.stanford.edu>
To: faculty@score
Subject: CSD Retreat
Most of the responses to my survey about having a CSD retreat were
positive, so I conclude that we should have one. The center of
gravity of opinion about content is that we should concentrate on
technical subjects, as we did last year, but with some time reserved
for discussing issues of strategic importance to the Dept. Most
people expressing any opinion at all preferred going to Chaminade
again. While the union of sets of unfavorable times was the universal
set, it appears that the weekend of May 6 & 7 appears ok to most.
So, I'll ask Joyce (hereby) to check with Chaminade about space for
the evenings of Friday, May 5 and Saturday, May 6 for a retreat
beginning late Friday afternoon, lasting all day Saturday, with a
possibility of extending into Sunday morning. I'll also ask Joyce to
conduct a poll of the faculty and senior research associates to see
whether they are "definite attendees," "maybes," or "definite no's"
for May 5-7.
Yours for a more cohesive and well informed department,
Nils
∂16-Jan-89 1107 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Tuesday Lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Jan 89 11:07:12 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 16 Jan 89 10:57:22-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA03853; Mon, 16 Jan 89 10:57:02 PDT
Date: Mon, 16 Jan 89 10:57:02 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8901161857.AA03853@Tenaya.stanford.edu>
To: faculty@score
Cc: xb.mmr@forsythe
Subject: Tuesday Lunch
Tomorrow, Jan 17, we will have as faculty lunch guests Bill Yundt of
Stanford's Information Resources (Networks) and Michael Roberts of
Educom. I have asked them to come to give their perspective on
national and international computer networks. (Probably all of you
have heard that the ARPAnet is going away as our main computer
communication channel and that NSFnet and other networks are coming
along.) Bill and Mike are on top of all of these matters so come
with your appetites and questions. 12:15 in mjh146. -Nils
∂16-Jan-89 1235 @Score.Stanford.EDU:hayes@arisia.xerox.com SITN
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Jan 89 12:35:48 PST
Received: from arisia.Xerox.COM by SCORE.STANFORD.EDU with TCP; Mon 16 Jan 89 12:33:12-PST
Received: by arisia.Xerox.COM
(5.59++/IDA-1.2.6) id AA04335; Mon, 16 Jan 89 12:32:51 PST
Date: Mon, 16 Jan 89 12:32:51 PST
From: Pat Hayes <hayes@arisia.xerox.com>
Message-Id: <8901162032.AA04335@arisia.Xerox.COM>
To: JMC@SAIL.STANFORD.EDU
Cc: ungar@SELF.STANFORD.EDU, faculty@SCORE.STANFORD.EDU,
csd@SCORE.STANFORD.EDU
In-Reply-To: John McCarthy's message of 13 Jan 89 16:56 PST <10$ti7@SAIL.Stanford.EDU>
Subject: SITN
Surely, its fairly straightforward. We cheat some kids of a full life
by allowing them to buy crack cheaply in the streets. The basic
premis is that "we" know more about some of what is good for "them"
than they do. This is a dangerous idea, admittedly, but isnt an
outrageous premis to apply to University education: I dont have
trouble with the idea that Faculty know more about the efficacy of
some forms of education than most Students do, if only because theyve
been around longer.
Pat
∂16-Jan-89 1245 @Score.Stanford.EDU:hayes@arisia.xerox.com More on the TV question
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Jan 89 12:45:36 PST
Received: from arisia.Xerox.COM by SCORE.STANFORD.EDU with TCP; Mon 16 Jan 89 12:43:10-PST
Received: by arisia.Xerox.COM
(5.59++/IDA-1.2.6) id AA04386; Mon, 16 Jan 89 12:42:48 PST
Date: Mon, 16 Jan 89 12:42:48 PST
From: Pat Hayes <hayes@arisia.xerox.com>
Message-Id: <8901162042.AA04386@arisia.Xerox.COM>
To: JMC@SAIL.STANFORD.EDU
Cc: allison@SHASTA.STANFORD.EDU, faculty@SCORE.STANFORD.EDU,
csd@SCORE.STANFORD.EDU
In-Reply-To: John McCarthy's message of 14 Jan 89 00:35 PST <L$PQs@SAIL.Stanford.EDU>
Subject: More on the TV question
Tapes do not have to be professionally produced to be saleable. The
Linguistics Institute held at Stanford 2 summers ago taped several of
its lectures and is now offering them for sale, and expects to make a
bundle of money. They are quite awfully produced: I know, I am in one
of them. ( A decision I now bitterly regret, not because of the money I
lost, but because they arent very good but will be for many
people their only evidence of my lecturing style. This illustrates
one of my own chief worries about lecturing to a camera, by the way. Maybe
this is mere ego, of course.)
Pat
∂16-Jan-89 1255 @Score.Stanford.EDU:hayes@arisia.xerox.com Professional TV lectures
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Jan 89 12:55:31 PST
Received: from arisia.Xerox.COM by SCORE.STANFORD.EDU with TCP; Mon 16 Jan 89 12:53:16-PST
Received: by arisia.Xerox.COM
(5.59++/IDA-1.2.6) id AA04748; Mon, 16 Jan 89 12:52:55 PST
Date: Mon, 16 Jan 89 12:52:55 PST
From: Pat Hayes <hayes@arisia.xerox.com>
Message-Id: <8901162052.AA04748@arisia.Xerox.COM>
To: CAB@SAIL.STANFORD.EDU
Cc: allison@SHASTA.STANFORD.EDU, faculty@SCORE.STANFORD.EDU
In-Reply-To: Chuck Bigelow's message of 14 Jan 89 07:52 PST <4$Vjb@SAIL.Stanford.EDU>
Subject: Professional TV lectures
Its silly to be so sarcastic. Talk to some academic publishers. MIT
press is very excited about the idea of a textbook in the form of a
videotape, and Addison-Wesley ( I think ) already has something rather
like it, a series of quite professionally produced tapes on AI which
they have been demonstrating at AI shows now for at least 2 years.
These guys are in it for the money, but if this catches on, then
Stanford had better start getting its faculty visible on such videos
somehow, or all the smart kids are going to much more excited by the
gems of exposition which they can see in their school libraries than
they are by Stanford entrance literature.
Pat
∂16-Jan-89 1314 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Text in programming language semantics
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Jan 89 13:13:56 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA02424; Mon, 16 Jan 89 13:13:15 PDT
Message-Id: <8901162113.AA02424@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Mon, 16 Jan 89 13:05:48 PST
Received: by BYUADMIN (Mailer R2.01A) id 5652; Mon, 16 Jan 89 12:47:03 MST
Date: Mon, 16 Jan 89 10:24:46 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Steve Stevenson <steve%HUBCAP.CLEMSON.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Steve Stevenson <steve%HUBCAP.CLEMSON.EDU@Forsythe.Stanford.EDU>
Subject: Text in programming language semantics
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
I'm looking for texts or articles in semantics. I want to cover the whole
landscape so tutorials, ``where are we now'', and ``heavy'' texts are
desired.
Please send your favorites and I'll post a summary.
Thanks.
Steve (really "D. E.") Stevenson steve@hubcap.clemson.edu
Department of Computer Science, (803)656-5880.mabell
Clemson University, Clemson, SC 29634-1906
∂16-Jan-89 1333 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu [moran@Warbucks.AI.SRI.COM: RFC: Ethics of the Internet]
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Jan 89 13:33:28 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 16 Jan 89 13:30:51-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA03958; Mon, 16 Jan 89 13:30:23 PDT
Date: Mon, 16 Jan 89 13:30:23 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8901162130.AA03958@Tenaya.stanford.edu>
To: faculty@score, xb.mmr@forsythe
Subject: [moran@Warbucks.AI.SRI.COM: RFC: Ethics of the Internet]
fyi:
------
Return-Path: <@Tenaya.stanford.edu,@Score.Stanford.EDU:moran@ai.sri.com>
Date: Mon, 16 Jan 89 11:35:10 PST
From: moran@Warbucks.AI.SRI.COM (Doug Moran)
To: aic-staff@Warbucks.AI.SRI.COM
Subject: RFC: Ethics of the Internet
Date: Sun, 15 Jan 89 18:48:42 PST
From: cliff@Csa5.LBL.Gov (Cliff Stoll)
Subject: Ethics of the Internet - Request for Comments
Network Working Group IAB
Request for Comments: PPPP January 1989
Ethics and the Internet
Status of this Memo
This memo is a statement of policy by the Internet Activities
Board concerning the proper use of the resources of the Internet.
Introduction
At great human and economic cost, resources drawn from the U.S. and government,
industry and the academic community have been assembled into a collection of
interconnected networks called the Internet. Begun as a vehicle for
experimental network research in the mid-1970's, the Internet has become an
important national infrastructure supporting an increasingly widespread,
multi-disciplinary community of researchers ranging, inter alia, from computer
scientists and electrical engineers to mathematicians, physicists, medical
researchers, chemists, astronomers and space scientists.
As is true of other common infrastructure (e.g. roads, water reservoirs and
delivery systems, and the power generation and distribution network), there is
widespread dependence on the Internet by its users for the support of
day-to-day research activities.
The reliable operation of the Internet and the responsible use of its resources
is of common interest and concern for its users, operators and sponsors. Recent
events involving the hosts on the Internet and in similar network
infrastructures underscore the need to reiterate the professional
responsibility every Internet user bears to colleagues and to the sponsors of
the system. To the extent that the Internet resources are provided by the U.S.
Government, this responsibility becomes a Federal matter above and beyond
simple professional ethics.
IAB Statement of Policy
The Internet is a national facility whose utility is largely a consequence of
its wide availability and accessibility. Irresponsible use of this critical
resource poses an enormous threat to its continued availability to the
technical community.
The U.S. Government sponsors of this system have a fiduciary responsibility to
the Legislature to allocate government resources wisely and effectively.
Justification for the support of this system suffers when highly disruptive
abuses occur. Access to and use of the Internet is a privilege and should be
treated as such by all users of this system.
The IAB strongly endorses the view of the Division Advisory Panel of the
National Science Foundation Division of Network, Communications Research and
Infrastructure which, in paraphrase, characterized as unethical and
unacceptable any activity which purposely:
(a) seeks to gain unauthorized access to the resources of the Internet
(b) disrupts the intended use of the Internet
(c) wastes resources (people, capacity, computer) through such actions
(d) destroys the integrity of computer-based information
or (e) compromises the privacy of users
The Internet exists in the general research milieu. Portions of it continue to
be used to support research and experimentation on networking. Because
experimentation on the Internet has the potential to affect all of its
components and users, researchers have the responsibility to exercise great
caution in the conduct of their work. Negligence in the conduct of
Internet-wide experiments is both irresponsible and unacceptable.
The IAB plans to take whatever actions it can, in concert with Federal agencies
and other interested parties, to identify and to set up technical and
procedural mechanisms to make the Internet more resistant to disruption. Such
security, however, is extremely expensive and may be counterproductive if it
inhibits the free flow of information which makes the Internet so valuable. In
the final analysis, the health and well-being of the Internet is the
responsibility of its users who must, uniformly, guard against abuses which
disrupt the system and threaten its long-term viability.
∂16-Jan-89 1402 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Faculty positions at University of Haifa
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Jan 89 14:02:17 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA08207; Mon, 16 Jan 89 14:01:38 PDT
Message-Id: <8901162201.AA08207@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Mon, 16 Jan 89 14:00:27 PST
Received: by BYUADMIN (Mailer R2.01A) id 6405; Mon, 16 Jan 89 13:13:06 MST
Date: Mon, 16 Jan 89 10:28:14 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
gadi RSMA309@HAIFAUVM.BITNETAIFAUVM>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: gadi moran <RSMA309%HAIFAUVM.BITNET@forsythe.stanford.edu>
Subject: Faculty positions at University of Haifa
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
UNIVERSITY OF HAIFA
DEPARTMENT OF MATHEMATICS AND COMPUTER SCIENCE
APPLICATIONS ARE INVITED FOR ANTICIPATED FACULTY POSITION IN ALL AREAS OF
COMPUTER SCIENCE. THE DEPARTMENT WISHES TO STRENGTHEN ITS PROGRAMS THAT
COMBINE MATHEMATICS AND COMPUTER SCIENCE. STRONG INTEREST IN BOTH
RESEARCH AND TEACHING ARE EXPECTED. SEND RESUMEE INCLUDING RESEARCH
INTERESTS, LIST OF PUBLICATIONS AND ASK FOR 3 REFERENCE LETTERSSENT TO:
PROFESSOR YAIR CENSOR, CHAIRMAN
DEPARTMENT OF MATHEMATICS AND COMPUTER SCIENCE
UNIVERSITY OF HAIFA
HAIFA 31999
ISRAEL.
Bitnet: rsma403@haifauvm
∂16-Jan-89 1403 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Towards an Online Rolodex
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Jan 89 14:03:34 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA08269; Mon, 16 Jan 89 14:02:52 PDT
Message-Id: <8901162202.AA08269@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Mon, 16 Jan 89 14:00:49 PST
Received: by BYUADMIN (Mailer R2.01A) id 6674; Mon, 16 Jan 89 13:28:30 MST
Date: Mon, 16 Jan 89 10:30:39 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
rig%THEORY.LCS.MIT.EDU@Forsythe.Stanford.EDU
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: rig%THEORY.LCS.MIT.EDU@Forsythe.Stanford.EDU
Subject: Towards an Online Rolodex
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Towards an Online Rolodex
The following is a suggested mechanism to help members of our
community find one another. Unfortunately, this scheme will allow
information to be retrieved only by those who can telnet to
sri-nic.arpa; if you are not in this category, you are still
encouraged to submit information and keep it up to date so others can
find you even if you can't find them.
To get listed in the database at sri-nic, just send a template like
the following one to registrar@sri-nic.arpa. The entry for HANDLE
should be left blank; blank entries are also fine in the other places
they appear.
FULL NAME: Person, J. Random
U.S. MAIL ADDRESS: Podunk University
123 Main Street
Podunk, NY 19999
PHONE: (212) 000-0000
AUTHORIZING HOST: THEORY.PODUNK.EDU
PRIMARY LOGIN NAME: jrp
PRIMARY NETWORK MAILBOX: jrp@THEORY.PODUNK.EDU
TERMINATION DATE:
HANDLE:
DELETE? (y/n):
To get information from the database, just telnet to sri-nic.arpa, and
type "whois" followed by a carriage return. You can learn how to
perform retrievals by typing "?" followed by a carriage return.
∂16-Jan-89 1406 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Finite Halting Problem Considered Solvable
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Jan 89 14:06:02 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA08491; Mon, 16 Jan 89 14:05:26 PDT
Message-Id: <8901162205.AA08491@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Mon, 16 Jan 89 14:01:21 PST
Received: by BYUADMIN (Mailer R2.01A) id 7245; Mon, 16 Jan 89 13:42:31 MST
Date: Mon, 16 Jan 89 10:32:35 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Dan Bernstein <phoenix!bernsten%PRINCETON.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Dan Bernstein <phoenix!bernsten%PRINCETON.EDU@Forsythe.Stanford.EDU>
Subject: Finite Halting Problem Considered Solvable
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
The halting problem is to determine whether a given program loops forever.
This is an uncomputable function of a program, as we all know.
But if a program is restricted to a finite number of states then the
problem is computable. The practical solution is that we run the program
on two machines with that number of states, one machine exactly twice as
fast as the other; if the program loops in time t to t+u, then we will
see the machines in exactly the same state at time 3t to 3t+3u.
Now consider modern, real computers.
The space needed for this is practical. But the time is a trickier
consideration. How do we compare the states of two computers? The
solution is that in unit time a computer modifies a bounded-size
portion of its state as expressed in bits. So we merely watch what
registers, memory bytes, etc. are changed, incrementing a difference
count when something is made different on the two machines and
decrementing it when something is made the same. As a matter of fact,
this (at least for memory) is already done by good caches. It would
be a simple modification to those caches designed for multiprocessors
to have them keep track of (1) registers and flags as well as memory
and (2) a difference count.
Of course, this eminently practical hardware solution is only
appropriate if the entire machine is involved in a single computation
that we don't want to have accidentally looping. But I'd say that
the problem is practically solvable in software for many situations.
For example, MACSYMA and similar programs could have a feature that
a user-defined function be run three times slower and have it detect
infinite loops of variables blah, blah, and blah in the function. I
would expect that this be restricted to non-recursively written functions,
and restricted to functions that don't use non-mathematical stuff like
reading from a disk file---but it's still quite doable and would be a
real, live, practical solution to the halting problem.
More ambitiously, I can see how a C compiler could compile a function to
detect infinite loops. The function would probably run somewhat slower
than just three times, as most optimizations would go down the drain and
dealing with the difference count would be a major speed factor relative
to the speed of single expressions. And yes, it would take double the
memory---which could be a problem if the function had an array taking
an amount of space comparable to the space available on the machine.
And I would expect the restriction that the function and everything it
calls must use only built-in C, no system calls or anything else possibly
external; and also that the function and everything it calls must only
use variables local to themselves. But after all these caveats this still
remains a valuable tool that I would have loved to have for testing many
programs: the practical solution to the halting problem.
---Dan Bernstein, bernsten@phoenix.princeton.edu
∂16-Jan-89 1406 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Theory positon at Michigan
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Jan 89 14:06:42 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA08510; Mon, 16 Jan 89 14:06:00 PDT
Message-Id: <8901162206.AA08510@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Mon, 16 Jan 89 14:01:27 PST
Received: by BYUADMIN (Mailer R2.01A) id 7323; Mon, 16 Jan 89 13:42:49 MST
Date: Mon, 16 Jan 89 10:35:04 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Kevin_Compton%UM.CC.UMICH.EDU@Forsythe.Stanford.EDU
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Kevin_Compton%UM.CC.UMICH.EDU@Forsythe.Stanford.EDU
Subject: Theory positon at Michigan
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
The following may be of interest to graduating or recently graduated
Ph. D.s in theory.
THEORY POSITION AT THE UNIVERSITY OF MICHIGAN
The Electrical Engineering and Computer Science Department at the
University of Michigan invites applications for a junior level
position in the theory of computation. Areas of specialization
sought include (but are not restricted to) parallel algorithms,
complexity theory, and logic in computer science, including semantics
of programming and natural languages.
Faculty doing research in theoretical areas :
Yuri Gurevich: logic, complexity theory, semantics
Bill Rounds: semantics of programming and natural languages
Quentin Stout: algorithms, parallel algorithms and architectures
Kevin Compton: logic, complexity theory, combinatorics
Deepak Sherlekar: combinatorial algorithms and VLSI
Todd Knoblock: proof theory and programming languages
Cordelia Hall: denotational semantics and functional programming
In addition, there is strong interaction with other groups in the
department and on campus, particularly in cognitive science and
mathematics.
The EECS department has about 100 faculty, 35 of whom are in computer
science. Ample funds for research startup and equipment are made
available to new faculty members. Ann Arbor is one of the most
pleasant small cities in the U.S.; it offers an abundance of cultural
activities, fine restaurants, affordable quality housing, and good
schools.
Please send resumes to:
Edward S. Davidson, Chairman
Electrical Engineering and Computer Science
University of Michigan
Ann Arbor, MI 48109-2122
USA
For additional information, contact
Kevin_Compton@um.cc.umich.edu phone: (313)763-9165
Bill_Rounds@um.cc.umich.edu phone: (313)764-9418
Quentin_F._Stout@um.cc.umich.edu phone: (313)763-1518
or write to the address above.
∂16-Jan-89 1407 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu an improved Boolean matrix multiplication algorithm
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Jan 89 14:07:32 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA08566; Mon, 16 Jan 89 14:06:46 PDT
Message-Id: <8901162206.AA08566@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Mon, 16 Jan 89 14:01:45 PST
Received: by BYUADMIN (Mailer R2.01A) id 7414; Mon, 16 Jan 89 13:45:07 MST
Date: Mon, 16 Jan 89 10:46:43 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Udi Manber <udi%ARIZONA.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Udi Manber <udi%ARIZONA.EDU@Forsythe.Stanford.EDU>
Subject: an improved Boolean matrix multiplication algorithm
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
A recent IPL paper by Atkinson and Santoro (Sept. 88) presented an
O(n~3/(log n)~1.5 ) algorithm for Boolean matrix multiplication.
Unlike the Four-Russian's result, the authors assume a uniform, as opposed
to logarithmic, cost model. Specifically, O(log n)-bit integer arithmetic
and random memory access take unit time (which seems to be a very reasonable
assumption that is made implicitly by many algorithms).
Gene Myers and I realized that with this model, the Four-Russians approach
is fairly easily improved to O(n~3/(log n)~2 ) time.
In general, the result holds for any finite, small algebra <S,+,*>,
provided only that + is associative.
Furthermore, it turns out that the algorithm requires
only O(n log n) bits of auxiliary memory if one assumes that the
resultant matrix is to be memory resident.
We haven't seen this result mentioned anywhere. The purpose of this
message is to sketch the result and ask if anyone has seen it in the
literature. References would be appreciated.
-- Udi Manber ( udi@arizona.edu )
(We assume some familiarity with the "Four-Russian" algorithm;
see, for example, Aho, Hopcroft, and Ullman [1974].
We describe it briefly in the next paragraph.)
Consider two n X n Boolean matrices A and B.
The "Four-Russians" algorithm divides A into groups of columns,
and B into groups of rows.
Each group contains k columns or rows.
For each i, we need to compute the product of the ith group of columns
of A with the ith group of rows of B.
This product can be done in time O(n~2 + n*2~k) by precomputing all possible
sums of rows from B's group.
There are 2~k subsets of rows, so the table has 2~k entries,
each one corresponds to a k-bit number.
Computing the product of one row R (of size k) from A's group
with B's group is the same as adding the rows corresponding to
the bits in R, which can be found in the Rth entry in the table.
(R serves as an integer and a k-bit Boolean vector at the same time.)
The table can be constructed in time O(n*2~k).
Since there are n/k groups, the running time of this algorithm is
O(n~3/k + n~2*2~k/k). By choosing k to be log n, we get a running time
of O(n~3/log n). The space requirements (if one is careful) is O(n~2).
We can improve this algorithm by another factor of log n by considering
each row of B as an n/m tuple of integers, each integer with m bits.
We construct a table of all possible Boolean sums of two m-bits
Boolean vectors. This is a two-dimensional table of size 2~m X 2~m.
Using this table, we can add two rows of B in n/m steps.
We use this trick both for the multiplication algorithm itself *and*
for building the tables for it.
Again, each m-bit Boolean vector serves as an integer and an index
to the table. By choosing m to be (log n)/2 we get a running time
of O(n~3/(log n)~2). We do not describe the implementation in detail,
but it is quite straightforward.
-----------------------------------------------------------------------
∂16-Jan-89 1502 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Registration information for EUROCRYPT '89
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Jan 89 15:02:30 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA13560; Mon, 16 Jan 89 15:01:44 PDT
Message-Id: <8901162301.AA13560@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Mon, 16 Jan 89 15:00:23 PST
Received: by BYUADMIN (Mailer R2.01A) id 7836; Mon, 16 Jan 89 14:05:01 MST
Date: Mon, 16 Jan 89 10:50:33 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Jac. Quisquater" <mcvax!prlb2!quisquat@UUNET.UU.NET>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Jac. Quisquater" <mcvax!prlb2!quisquat@UUNET.UU.NET>
Subject: Registration information for EUROCRYPT '89
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
REGISTRATION INFORMATION
EUROCRYPT '89
April 10-13, 1989
Houthalen, BELGIUM
A WORKSHOP ON THE THEORY AND APPLICATIONS OF CRYPTOGRAPHIC TECHNIQUES
An international conference sponsored by the
International Association for Cryptologic Research (IACR)
Organizing Committee
Joos Vandewalle (General chairman)
Tri An Banh (ULg, Li`ege)
Marijke De Soete (RUG, Gent)
Jean Doyen (ULB, Bruxelles)
Jean-Marie Goethals (UCL, Louvain-la-Neuve)
Ren'e Govaerts (KUL, Leuven)
Emile Peeters (CEC, Brussels)
Jean Ramaekers (FUN, Namur)
Bart Preneel (Local arrangement)
Program committee
Jean-Jacques Quisquater (Program chairman)
Paul Camion (INRIA, Rocquencourt)
Yvo Desmedt (UW, Milwaukee)
Louis Guillou (CCETT, Rennes)
Johan H\astad (RIT, Stockholm)
Lloren\c Huguet (UAB, Barcelona)
Wyn Price (NPL, Teddington)
Rainer Rueppel (Crypto AG, Steinhausen)
Johan van Tilburg (PTT-DNL, Leidschendam)
SUBJECT
The conference deals with all aspects of the theory and the application of
cryptography including symmetric and asymmetric ciphers, authentication,
protocols, secure transactions, signatures, sequences and linear complexity,
hardware and software topics, security of telecommunication systems and computer
networks. The program includes a rump session and a session on open problems.
The proceedings of the workshop will be published by Springer Verlag in the
Lecture Notes in Computer Science series.
LOCATION
The meeting will be held in the calm, spacious and relaxing atmosphere of the
Conference Centre Hengelhoef, 80 km east of Brussels.
(address : Domein Hengelhoef, Hengelhoefdreef 1, B-3530 Houthalen-Helchteren,
telephone : +32-11-38 01 16, telex : 39 345 hengel)
The Centre is situated in the heart of Limburg, in the midst of a large park
with woods and ponds. It offers a wide range of sports accomodations. Further
details about tourist information will be mailed with the confirmation of your
registration.
ACCOMODATIONS
Conference attendees and accompanying persons will be accomodated in
200 studio-apartments grouped around the congress building. These
studio-apartments are completely equipped, a sitting-room, a kitchenette, toilet
and shower, a private terrace, and sleeping facilities with one or two beds.
The price for a single/double room and breakfast will be 4,000/3,000 Bfr.
(1 US$ = +/- 37 Bfr). Reservations can be extended before and after the
conference.
TRANSPORTATION
Houthalen is only 80 kilometers away from Brussels airport. A bus service will
be provided just before and after the conference. It is also possible to take
the train via Brussels to Hasselt. The Centre is served by a bus service from
Hasselt. Finally, if you are arriving by car, the Centre is near to the exit
30 ``Park Midden Limburg'' of the E 314 freeway. Further details will be
provided with the confirmation of your registration.
CONFERENCE EVENTS
The conference starts on Monday, April 10th with lunch and ends on Thursday,
April 13th early afternoon. Social activities, including a reception, a rump
session and a banquet are planned for the evenings. A short visit to the Bokrij
open air museum is scheduled on Monday late afternoon. There will be an IACR
Business meeting on Thursday morning.
CLIMATE
Although weather during April can be cool, (10 - 15 degree Celsius) with a good
chance on rain, sunny - and warmer - days are quite likely.
REGISTRATION !!!!!!!! DEADLINE : MARCH 15, 1989 !!!!!!!!
The workshop fee is 12,000 Bfr. This fee includes four lunches, coffee breaks,
the Monday evening aperitif and dinner, Tuesday evening rump session and dinner,
Wednesday evening banquet and the dues to the International Association for
Cryptologic Research (IACR). These later dues entitle you to become a member of
the IACR for 1990 without any additional payment and to receive the IACR's
Journal of Cryptology, published by Springer Verlag, free of charges during
that year. The workshop fee must be paid upon registration, which should be
performed before March 15, 1989. There will be no registration at the door.
A reduced workshop fee of 8,000 Bfr. is offered to full time students,
undergraduate or graduate, if their registration form is accompanied by a
certification of their student status.
The fee for accompanying persons is 10,500/9,500 Bfr. for a single/double room.
It includes Room and Board and all social activities (visit, banquet, ... ).
REGISTRATION FORM
deadline : March 15, 1989
NAME AND ADDRESS Sex : 0 M 0 F
Title : _____ First Name : ____________________ Surname : ____________________
Affiliation : ________________________________________________________________
Street : _____________________________________________________________________
Zip : ____________ City : _______________________ Country : __________________
Phone : __________________ Fax : __________________ Email : __________________
IACR MEMBERSHIP FOR 1990 (no additional payment) 0 yes 0 no
HOTEL RESERVATION
Number of accompanying persons : _______
Reservation of _______ single room(s) (assigned according to registration date)
Reservation of _______ double room(s) preferred roommate : ____________________
Date of arrival : April ____________ Date of departure : April _____________
TRANSPORTATION
I would like to use the special bus
0 no 0 yes and I expect to arrive at ___________ and to leave at ___________
EXCURSION
0 I intend to join the guided tour (+/- 1 hour) at the Bokrijk open air museum
(in the price included) and will be accompanied by _____ persons.
PAYMENT
Workshop fee+Lunch+Dinner (12,000 Bfr. / 8,000 Bfr. for students) ________ Bfr.
Room + Breakfast (4,000/3,000 Bfr. single/double) ________ Bfr.
Accompanying person(s) (10,500/9,500 Bfr. single/double) ________ Bfr.
After deadline registration penalty (2,000 Bfr.) ________ Bfr.
Total Amount ________ Bfr.
US citizens can pay in US$ (28 $ = 1000 Bfr) ________ US$
0 I enclose a check payable to EUROCRYPT-'89-IACR
0 I have transferred the money to Generale Bank of Belgium
EUROCRYPT-'89-IACR 230-0477050-24
Please mention your name on the check or on the money transfer in order to avoid
anonymous payments.
Date : ______________ Signature:
Please send this form or a facsimile to :
ir. Bart Preneel Phone : +32-16-220931
ESAT Katholieke Universiteit Leuven Telex : 25941 elekul
Kard. Mercierlaan, 94 Fax : +32-16-221855
B-3030 Heverlee Email : eurocrypt@kulesat.uucp
Belgium
Remarks :
∂16-Jan-89 1503 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Solving BITMAP Rotation in place
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Jan 89 15:03:19 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA13712; Mon, 16 Jan 89 15:02:32 PDT
Message-Id: <8901162302.AA13712@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Mon, 16 Jan 89 15:00:39 PST
Received: by BYUADMIN (Mailer R2.01A) id 7910; Mon, 16 Jan 89 14:05:23 MST
Date: Mon, 16 Jan 89 10:54:03 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Steve <ganelon.usc.edu!robiner%OBERON.USC.EDU@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Steve <ganelon.usc.edu!robiner%OBERON.USC.EDU@Forsythe.Stanford.EDU>
Subject: Solving BITMAP Rotation in place
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Here is the situation: I need to rotate an M x N array in place
with little additional memory. I have perhaps 4M buffer space,
but I'd like to be able to do it with no extra memory if possible.
For M=N, ie a sqaure the problem is easy, mearly swap the elements with
the ones at their new, rotated loacation, ie 1,1 gets swaped with 1,M,
etc.
The problem arrises for any non-square array: the elements do
not get swaped, but rather, there is a cycle of replacements,
eventually leading back to the original element. For example, if we start
with element number 1,1 its new location might be 1,35 but 1,35's new
location is not necessarily 1,1; it may be 23,78 or something completely
different. So when the cycle is finished, some of the elements are now in
their correctly rotated positions, but there is no way of telling which ones
have already been done, and which ones haven't.
So basically, I'd like to know if there's a simple algorithm to acomplish
this 90 degree rotation for any M by N array with as little additional memory
as possible.
To help out, here's a formula which gives the vector for a linear array
representing the 2D array.
v=IM+J
v is the vector, I is the element across, J is the element down.
M is the width of the array.
the rotated formula is:
vr=JN+N-1-I
M is not needed here, just the array height, N.
PLEASE SEND ME E-MAIL RESPONSES, I DO NOT REGULARLY READ THESE BOARDS.
I WILL POST RESULTS IF THERE IS INTEREST.
Thanks in advance,
=Steve= robiner@ganelon.usc.edu robiner@usc-ganelon.edu
------------------------------------------------------------------------
Date: 15 Jan 89 21:14:41 GMT
From: Krulwich-Bruce@yale-bulldog.arpa (Bruce Krulwich)
Organization: Computer Science, Yale University, New Haven, CT 06520-2158
Subject: Re: Solving BITMAP Rotation in place
Message-Id: <47555@yale-celray.yale.UUCP>
References: <14687@oberon.USC.EDU>
In article <14687@oberon.USC.EDU>, robiner@ganelon (Steve) writes:
>Here is the situation: I need to rotate an M x N array in place
>with little additional memory. I have perhaps 4M buffer space,
>but I'd like to be able to do it with no extra memory if possible.
I am assuming that you want to rotate a matrix 90 degrees counter-clockwise,
which is what I gather from your discussion below. The formulas you give
below are for storing a matrix in column-major form in a vector. I interpret
this to be referring to switching elements in-place in the vector
representation and then interpreting it as a matrix of the appropriate new
size.
>For M=N, ie a sqaure the problem is easy, mearly swap the elements with
>the ones at their new, rotated loacation, ie 1,1 gets swaped with 1,M,
>etc.
I don't think that this is correct. Why are the changes for a square matrix
swaps?? For example, for a 2x2 matrix, the 1,1 element goes to 1,2 and the
1,2 element goes to 2,2, etc. In particular, applying the formulas below to
the representation of a 2x2 matrix do not result in all elements being
swapped:
1 2 => 1 3 2 4
3 4
2 4 => 2 1 4 3
1 3
>The problem arrises for any non-square array: the elements do
>not get swaped, but rather, there is a cycle of replacements,
>eventually leading back to the original element. For example, if we start
>with element number 1,1 its new location might be 1,35 but 1,35's new
>location is not necessarily 1,1; it may be 23,78 or something completely
>different. So when the cycle is finished, some of the elements are now in
>their correctly rotated positions, but there is no way of telling which ones
>have already been done, and which ones haven't.
As I said above, I think that this is the case for all matricies, not just
non-square ones.
>So basically, I'd like to know if there's a simple algorithm to acomplish
>this 90 degree rotation for any M by N array with as little additional memory
>as possible.
>
>To help out, here's a formula which gives the vector for a linear array
>representing the 2D array.
>
>v=IM+J
>
>v is the vector, I is the element across, J is the element down.
>M is the width of the array.
I think that this is nonstandard notation. Don't I and J usually refer to row
and column, respectively?? In any case...
>the rotated formula is:
>
>vr=JN+N-1-I
>
>M is not needed here, just the array height, N.
This seems easy. from V=IM+J you get:
I = V mod M
J = floor(V / M)
and thus
VR(V) = (V mod M) * N + N - 1 - floor(V / M)
Thus in the rotation, the element in V (for all V) should be moved to VR(V).
This is simply a permutation of the elements of the matrix. An example is
the rotation:
1 2 3 (M = 2, N = 3)
4 5 6
which is represented as:
1 4 2 5 3 6
which (applying the rotation formulas you give) becomes:
3 2 1 6 5 4
which represents the (correct) matrix:
3 6
2 5
1 4
The permutation of the representation vector (shown in standard "cycle
notation") is:
(0 2 1 5 3 4)
The important thing to see is that this permutation is subcycle-free. This
means that it can be made with a constant amount of extra memory, by starting
at V=0 and doing the permutation from V to VR(V), setting V to VR(V) after
each move, and looping until VR(V)=0. If the permutation was not
subcycle-free you would need memory to store the permutation itself, or
(equivalently) to mark which elements of the matrix had been forwarded.
You could tell if a permutation is not subcycle-free by incrementing a counter
each time through the loop and checking at the end if it is equal to M*N.
I have found that a 2x2 matrix rotation is also subcycle-free. If you can
show (theoretically or emprically) that rotation permutations are always
subcycle-free, you have proven that rotations can always be done with constant
extra memory as I described.
Bruce Krulwich
krulwich@cs.yale.edu
∂16-Jan-89 1602 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu ASL logic meeting at UCLA
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Jan 89 16:02:12 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA16864; Mon, 16 Jan 89 16:01:35 PDT
Message-Id: <8901170001.AA16864@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Mon, 16 Jan 89 16:00:38 PST
Received: by BYUADMIN (Mailer R2.01A) id 8413; Mon, 16 Jan 89 14:26:45 MST
Date: Mon, 16 Jan 89 10:38:16 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
math.ucla.edu!hbe%CS.UCLA.EDU@Forsythe.Stanford.EDU
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: math.ucla.edu!hbe%CS.UCLA.EDU@Forsythe.Stanford.EDU
Subject: ASL logic meeting at UCLA
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
ASSOCIATION FOR SYMBOLIC LOGIC
Annual Meeting
University of California, Los Angeles
January 14-17, 1989
All invited lectures will take place in the Mathematical Sciences (MS)
Building room MS 4000A except those on Tuesday, January 17, which will
be in the Factor Auditorium. Coffee and tea will be served in the
Mathematics Department lounge, MS 6620, where the registration table
is locatied. Book displays will be in MS 6943.
Saturday, January 14
Afternoon Session
1:30-2:20 Theodore Slaman: Higher recursion theory: the next generation.
2:30-2:50 Tea
3:00-3:50 Edward L. Keenan: Some results on generalized quantifiers in
natural language.
4:00-5:25 Sessions for contributed papers, MS 5117 and MS 5118; see
listing below.
5:30-7:00 Informal get-together in the lounge, MS 6620.
7:00-10:00 Council meeting and dinner, room to be announced.
Sunday, January 15
Morning Session
8:10-9:20 Sessions for contributed papers, MS 5117 and 5118; see
listing below.
9:30-10:20 Matt Foreman: The current cardinality of the continuum.
10:30-10:50 Coffee
11:00-11:50 Alistair Lachlan: Monadic stability.
Afternoon Session
2:00-2:50 Penelope Maddy: Contemporary Platonism.
3:00-3:20 Tea
3:30-5:30 Michael Beeson, John Mitchell, and Andre Scedrov: A Symposium
on Type Theory.
8:00-12:00 Party at "the Penthouse," Boelter Hall room BH 8500.
Monday, January 16
Morning Session
8:10-9:20 Sessions for contributed papers, MS 5117 and MS 5118; see
listing below.
9:30-10:20 Richard Cartwright: Speaking for everything: unrestricted
quantification.
10:30-10:50 Coffee
11:00-11:50 Ronald Fagin: Reachability is harder for directed than for
undirected finite graphs.
Afternoon Session
2:00-2:50 John Steel: Determinacy, large cardinals, and inner models.
3:00-3:20 Tea
3:30-4:20 Neil Immerman: Logic and complexity.
4:30-6:10 Sessions for contributed papers, MS 5117 and 5118; see
listing below.
8:30-11:00 Council meeting, MS 6943.
Tuesday, January 17
Morning Session
8:10-9:20 Sessions for contributed papers, Ackerman 2048 & Kerckhoff 400;
see listing below.
9:30-10:20 Manuel Lerman: 0(n) priority arguments and sequences of
trees and strategies.
10:30-10:50 Coffee (Factor Auditorium lobby)
11:00-11:50 Angus Macintyre: Transfer principles: the analogy between
numbers and functions.
CONTRIBUTED PAPERS
Saturday, January 14
Afternoon Session
Room MS 5117
4:00-4:20 S. S. Goncharov: Unique positive numerations.
4:25-4:45 Antonin Kucera: Diagonally non-recursive functions.
4:50-5:10 Kyriakos Kontostathis: Category and the finite injury
priority argument.
5:15-5:25 Robert Lubarsky: Gamma-recursion theory.
Room MS 5118
4:00-4:20 Gian Arturo Marco: Logical problems about compositionality
and information.
4:25-4:45 Leona Fass: Remarks on inductive inference and testing.
4:50-5:10 Peter Gabrovsky: Connecting higher-order logic with
generalized recursion theory.
5:15-5:25 Raymond D. Gumb: Free arithmetic.
Sunday, January 15
Morning Session
Room MS 5117
8:10-8:30 Robert C. Reed: Decidable theories with finitely many models
some of which are hyperarithmetic.
8:35-8:55 Sarah E. Oates: Jump degrees of groups.
9:00-9:20 Xiaokang Yu: Integration in subsystems of second order
arithmetic.
Room MS 5118
8:10-8:30 Frank J. Wroblewski: Quine's semantics reduced to trivalent
logic, type-freed and extended to algebra with AC.
8:35-8:55 Trip McCrosin: Identity and relational properties.
9:00-9:20 Hugues Leblanc and Peter Roeper: Of probability functions and
Boolean algebras.
Monday, January 16
Morning Session
Room MS 5117
8:10-8:30 Ali Enayat: Counting countable well-founded models of set
theory.
8:35-8:55 Kenneth Manders: Model completeness and the classical
geometries.
9:00-9:20 George Weaver: A downward Skolem-Lowenheim theorem for
elementary extensions.
Room MS 5118
8:10-8:30 James Hook and Garrel Pottinger: Natural L-systems.
8:35-8:55 Jonathan P. Seldin: On the proof theory of Coquand's calculus
of constructions.
9:00-9:20 William M. Farmer, John D. Ramsdell, and Ronald J. Watro: A
correctness proof for combinator reduction with cycles.
Afternoon Session
Room MS 5117
4:30-4:50 Tapani Hyttinen: Games and languages.
4:55-5:10 Yechiel Kimchi: Reflecting measurables and partition relations.
5:15-5:35 John C. Simms: Another characterization of alephs.
5:40-6:10 Donald H. Pelletier: Strong normality and the disjointing
property for ideals on P(kappa, lambda).
Room MS 5118
4:30-4:50 Douglas Cenzer and Jeffrey Remmel: Polynomial-time complexity
of models.
4:55-5:10 Judy Goldsmith, Deborah Joseph, and Paul Young: A note on
bi-immunity and p-closeness of p-cheatable sets in P/POLY.
5:15-5:35 Alasdair Urquhart: Complexity of decision problems in relevance
logic.
5:40-6:10 Daniel Leivant: Abstraction and computational complexity.
Tuesday, January 17
Morning Session
Ackerman 2048
8:10-8:30 Jan Krajicek: Two theorems on bounded arithmetic.
8:35-8:55 Peter B. Ladkin and Roger D. Maddux: The algebra of Boolean
constraint satisfaction.
9:00-9:20 Gregory L. McColm: Automata and one-dimensional inductions.
Kerckhoff 400
8:10-8:30 Robert Tieszen: Intuitionism with intuition.
8:35-8:55 Wim Ruitenburg: Inequality in constructive mathematics.
9:00-9:20 Philip Scowcroft: A new model for intuitionistic analysis.
Papers contributed by title:
Zbigniew A. Nowacki: Ultraproduct theorem for higher order logic.
∂16-Jan-89 1606 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Call for Participation
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Jan 89 16:06:07 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA17021; Mon, 16 Jan 89 16:05:27 PDT
Message-Id: <8901170005.AA17021@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Mon, 16 Jan 89 16:02:33 PST
Received: by BYUADMIN (Mailer R2.01A) id 9088; Mon, 16 Jan 89 15:05:22 MST
Date: Mon, 16 Jan 89 10:41:49 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
clayton%MORGUL.PSC.EDU@Forsythe.Stanford.EDU
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: clayton%MORGUL.PSC.EDU@Forsythe.Stanford.EDU
Subject: Call for Participation
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
S U P E R C O M P U T I N G ' 89
C A L L F O R P A R T I C I P A T I O N
Supercomputing '89 continues the tradition established at the '88 Conference
and will bring together supercomputing system researchers, designers, managers,
and computational scientists and engineers to report advances and experiences,
state needs, suggest future directions and exchange information. It will
include a technical program of invited and contributed papers, tutorials,
poster sessions, vendor and research exhibits, and product briefings and
demonstrations.
NOVEMBER 13-17, 1989
RENO/SPARKS CONVENTION CENTER
RENO, NEVADA
Sponsored by: ACM SIGARCH and Computer Society of the IEEE
In cooperation with: Argonne National Laboratory, Lawrence Livermore National
Laboratory, Los Alamos National Laboratory, NASA Ames Research Center, National
Center for Atmospheric Research, National Science Foundation, SIAM Activity
Group on Supercomputing, and the Supercomputing Research Center
Topics of Interest
Examples include, but are not limited to, the following:
computational science and engineering applications, parallel
and distributed processing, the impact of new technology on the
future of supercomputing, supercomputing environment, high
performance architectures, supercomputing systems evaluation,
systems software and languages, supercomputing management
issues, technical aspects of products, user experiences.
Papers Authors are invited to submit papers which report concrete
results and experiences. Papers reporting important negative
results are also encouraged. Referee's selection criteria will
include originality, clarity, and relevance.
Requirements
Papers must be original material not previously published.
Papers must be submitted without conditions; authors must
obtain any necessary approvals and/or clearances prior to
submission. Copyright release will be required. Authors of
accepted papers will be responsible for retyping corrected
papers on special forms to be provided and for preparing visual
material for their presentations using guidelines to be
provided. Camera-ready copy is due August 15, 1989.
Instructions
Submit five copies to the Program Chairperson by May 1, 1989.
Papers must be in English, typed double-spaced, and not exceed
25 pages (about 5,000 words). Papers must have: a title page
that lists the name, mailing and electronic address, and
telephone number for each author, an abstract, keywords and the
presentation media requirements. For multiple author papers,
identify the corresponding author and the presenting author.
Posters Authors who prefer an informal environment that fosters
interaction with the conference attendees are encouraged to
submit poster proposals. A book of abstracts of poster
presentations will be available at the conference.
Requirements
concise statement of the problem and the results should be a
conspicuous part of the display. Authors will be expected to
make themselves available to the audience for approximately two
hours, during which time they explain their work and discuss it
in depth. Authors of accepted posters will be responsible for
supplying a camera-ready abstract (not to exceed 100 words) by
August 15, 1989.
Instructions
Submit five copies of the poster proposal to the Program
Chairperson by June 1, 1989. The proposal should not exceed
five pages (about 1,000 words). Other aspects of the proposal
should conform to the instructions for submission of papers, as
listed above.
Vendor Exhibits An opportunity exists for vendors to exhibit their
supercomputing technology during three days of Supercomputing
'89. Interested parties should contact the Exhibits
Chairperson as soon as possible to arrange for floor space.
Research Exhibits
A limited amount of space will be set aside at Supercomputing
'89 to allow researchers to set up and exhibit or demonstrate
their work. Research exhibits will provide a joint
opportunity--an opportunity for the researcher to demonstrate
his or her work to a broader audience of potentially interested
users and an opportunity for the conference attendees to see a
broad range ofsupercomputing-oriented research which represents
some of the important technical directions of the future. The
possibility exists that, by special arrangement, research
exhibitors may be able to make use of equipment on display at
the vendor exhibit.)
Requirements
Research exhibitors should provide a description of their
exhibit/demonstration including: the type of audience
expected; required facilities; organizational affiliation of
exhibitors and acknowledgement of research sponsors;
acknowledgement of responsibility for (a) staffing the exhibit
during conference hours (unless the exhibit is totally static
and self-explanatory) and (b) transportation of the exhibit to
and from the conference, as well as all expenses associated
with setup and teardown.
Instructions
Submit a brief proposal to the Exhibits Chairperson as soon as
possible, but not later than March 31, 1989.
Tutorials The traditional half-day or full-day lecture style presentation
with view-graphs distributed to attendees.
Instructions
Submit proposal by February 28, 1989 to Tutorials
Chairperson.Include a succinct description of intended
audience, abstract and lecture outline with view-graphs (if not
yet available, state when will be available), and vita with
three references who are familiar with your lecturing ability.
Extended Tutorials
Provide an opportunity for a mini-course introduction to a
topic. The course begins before the conference with advanced
mailing of course material. The organizer will receive a list
of attendees and their biographies ahead of time and have an
opportunity to "tune" the course to their needs. This is
intended to be a long day of intense learning and
ex↔plo↔ra↔tion.
Instructions
Submit proposal by February 28, 1989 to Tutorials Chairperson.
Include succinct course objectives, targeted participants
characteristics, references to be distributed, vita and related
teaching experience of organizer.
Workshops Workshops are of the "birds-of-a-feather" variety, where
registrants participate in an interactive workshop environment.
The organizer is a participant/facilitator rather than a
lecturer.
Instructions
Submit proposal by April 30, 1989 to Tutorials Chairperson.
Include a sampling of co-workers in their field, suggestions
for invitees, organizers, contributions/role in the field and
vita.
Committee Chairpersons:
General Chairperson
F. Ron Bailey
Mail Stop 258-5
NASA Ames Research Center
Moffett Field, CA 94035
415/694-4500
rbailey@prandtl.nas.nasa.go
Program Chairperson
Gary Johnson
San Diego Supercomputer Center
P. O. Box 85608
San Diego, CA 92138
619/534-5181
garyj@sds.sdsc.edu
Tutorials Chairperson
John Riganati
Supercomputing Research Center
4380 Forbes Boulevard
Lanham, MD 20706
301/731-3741
riganati%super.org@sh.cs.net
Exhibits Chairperson
Howard Johnson
15694 East Chenango
Aurora, CO 80015
303/693-8291
howardj%csugreen.bitnet
@cunyvm.cuny.edu
Registration Chairperson
Lyz Dunham
Mail Stop 258-6
NASA Ames Research Center
Moffett Field, CA 94035
415/694-4370
dunham@prandtl.nas.nasa.go
Finance Chairperson
Ray L. Elliott
P. O. Box 1663
Los Alamos, NM 87545
505/667-1449
rle%a@lanl.go
Publications Chairperson
Lt. Col. C. Edward Oliver
Chief Scientist
Air Force Weapons Laboratory
Kirtland AFB, NM 87117-6008
505/844-9856
oliver@lbl-csam.arpa
Publicity Chairperson
Beverly C. Clayton
Pittsburgh Supercomputing Center
4400 Fifth Avenue
Pittsburgh, PA 15213
412/268-4960
clayton@morgul.psc.edu
∂17-Jan-89 0933 @Score.Stanford.EDU:goldberg@polya.Stanford.EDU Re: More on the TV question
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Jan 89 09:33:19 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 17 Jan 89 09:30:26-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA11770; Tue, 17 Jan 89 09:31:15 PDT
Date: Tue 17 Jan 89 09:31:14-PST
From: Andrew V. Goldberg <GOLDBERG@Polya.Stanford.EDU>
Subject: Re: More on the TV question
To: allison@shasta.stanford.edu
Cc: faculty@score.stanford.edu
Message-Id: <601061474.0.GOLDBERG@Polya.Stanford.EDU>
In-Reply-To: <8901140805.AA24384@polya.Stanford.EDU>
Mail-System-Version: <VAX-MM(229)+TOPSLIB(128)@Polya.Stanford.EDU>
What is the purpose of the TV program? It seems that it is to raise money.
In this case, how about some adds?
--Andy
-------
∂17-Jan-89 1129 @Score.Stanford.EDU:bhayes@polya.Stanford.EDU Re: Occasional summaries of student opinion
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Jan 89 11:29:22 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 17 Jan 89 11:26:25-PST
Received: from LOCALHOST by polya.Stanford.EDU (5.59/25-eef) id AA18375; Tue, 17 Jan 89 11:27:13 PDT
Message-Id: <8901171927.AA18375@polya.Stanford.EDU>
To: Vaughan Pratt <coraki!pratt@Sun.COM>
Cc: faculty@score.stanford.edu, csd-bboard@polya.Stanford.EDU
Subject: Re: Occasional summaries of student opinion
In-Reply-To: Your message of Sun, 15 Jan 89 11:28:28 -0800.
<8901151928.AA24919@>
Date: Tue, 17 Jan 89 11:27:10 -0800
From: bhayes@polya.Stanford.EDU
Vaughn says...
>I for one would appreciate seeing on this mailing list an occasional
>summary of recent trends in student opinion. How about if the student
>bureaucrats take on the responsibility for this? An appropriate
>startup strategy would be for them to do it themselves in the beginning
>to debug the process, then delegate the work if it gets too
>burdensome.
I sez-
No. The students do not seem to be hiding their opinions. Those
faculty who are truly interested can talk with students or read any of
the bboards set up for the purpose of communication. I do not feel
that being "responsible for communication" is any more a student job
than a faculty job. [Perhaps you would like to volunteer?]
Students are posting messages about the TV lectures in csd.bboard. Not
as many as the faculty seem to be posting, perhaps four or five
messages, and some of them are valuable. I would think that if the
faculty were interested in student opinion they would talk with the
students. I would very much like to hear from any faculty member who
has asked a student how he or she feels about TV classes.
Sorry about grandstanding, Vaughn. Your letter just provided a good
starting point.
∂17-Jan-89 1444 misha@polya.Stanford.EDU Next AFLB
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Jan 89 14:44:28 PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA02171; Tue, 17 Jan 89 14:42:38 PDT
Date: Tue, 17 Jan 89 14:42:38 PDT
From: Michael Kharitonov <misha@polya.Stanford.EDU>
Message-Id: <8901172242.AA02171@polya.Stanford.EDU>
To: aflb-all@polya.Stanford.EDU
Subject: Next AFLB
Please note UNUSAL time and place: next week there will be two AFLB sessions:
David Shmoys from MIT will speak on Tuesday at 4:15 in room 301 and Eva Tardos
from MIT will speak at the regular session on Thursday at 12:30 in room 352.
This week's talk will be by Bernd Sturmfels on Thursday, January 19, 12.30 pm,
in room 352:
RECENT APPLICATIONS OF GROBNER BASES THEORY
B.cBuchberger's Gr\"obner bases theory provides both
a theoretical framework and practical algorithms for large class
of computational problems in algebraic geometry.
Moreover, implementations of the basic algorithms are
now available in many computer algebra systems
(e.g. MAPLE, MACSYMA, SCRATCHPAD, REDUCE, ...).
After a brief introduction to Gr\"obner bases
``from a user's point of view'', we will discuss recent
applications of these methods to problems in the following areas:
Computational invariant theory
Inverse kinematics in robot programming
Determinantal ideals and algebraic combinatorics
Algorithmic versions of the Quillen-Suslin theorem
----------------------------------------------------------
Also on Friday, January 20, at 3:15 pm Dr. Sturmfels will give a talk in
the Math department:
SEMI-ALGEBRAIC GEOMETRY OF ORIENTED MATROIDS
∂17-Jan-89 1605 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu yet another bibliography request: logic programming
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Jan 89 16:05:24 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA07437; Tue, 17 Jan 89 16:04:35 PDT
Message-Id: <8901180004.AA07437@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 17 Jan 89 16:03:41 PST
Received: by BYUADMIN (Mailer R2.01A) id 7456; Tue, 17 Jan 89 17:02:07 MST
Date: Tue, 17 Jan 89 16:50:49 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Steve Stevenson <steve@HUBCAP.CLEMSON.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Steve Stevenson <steve@HUBCAP.CLEMSON.EDU>
Subject: yet another bibliography request: logic programming
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
[ I'm back on the bibliography kick again ---- :-) ]
I am trying to compile a bibliography on the history, development, and
``state of the art'' of logic programming ( NOT just prolog). I am
interested primarily in the foundational and implementation issues ( again
not restricted to prolog). Here, foundational means semantics, ties
to logic, etc.
Please send your nominees for inclusion directly to
``steve@hubcap.clemson.edu''. If you have things in either BibTeX or
refer format, please leave them in that format (it's easier to work with).
I'll put it all in a common (refer) format and distribute to whoever is
interested.
Thanks
Steve
Steve (really "D. E.") Stevenson steve@hubcap.clemson.edu
Department of Computer Science, (803)656-5880.mabell
Clemson University, Clemson, SC 29634-1906
∂17-Jan-89 1629 @polya.Stanford.EDU:DEK@SAIL.Stanford.EDU Wednesday not Friday
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Jan 89 16:29:41 PST
Received: from Sail.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA09627; Tue, 17 Jan 89 16:28:05 PDT
Message-Id: <10btJU@SAIL.Stanford.EDU>
Date: 17 Jan 89 1624 PST
From: Don Knuth <DEK@SAIL.Stanford.EDU>
Subject: Wednesday not Friday
To: aflb-all@Polya.Stanford.EDU
Correction: Bernd Sturmfels will speak about oriented matroids
TOMORROW, Wednesday, at 3:15 in the math building. (See the
announcement posted in the math elevator. There are refreshments
starting at 2:30.) On Friday afternoon there's a special lecture
by Michael Atiyah. Lots of good stuff this week and next week and
all quarter!
∂17-Jan-89 1748 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu dismay
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Jan 89 17:48:16 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 17 Jan 89 17:45:51-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA04857; Tue, 17 Jan 89 17:45:24 PDT
Date: Tue, 17 Jan 89 17:45:24 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8901180145.AA04857@Tenaya.stanford.edu>
To: faculty@score
Subject: dismay
I must confess to being somewhat disappointed at the essentially zero
faculty turnout at the Departmental Colloquium this afternoon.
I had thought that the faculty wanted us to restart the colloq series,
especially if we did it biweekly instead of weekly, got more prominent
speakers, and held it closer to MJH and not at Terman. To be sure,
everyone is very busy, and we don't need more random things to occupy
our time---but I was working under the assumption that the colloq was
something we wanted to attend. We did have several students turn out,
and it may be worthwhile to have a "departmental colloquium" even
though only students attend. I would like to hear if people think
something went wrong in planning this series, if there are
circumstances (still unmet) under which people would want to go to a
departmental colloquium, and/or if people think that today's faculty
disinterest was for some reason non-typical.
-Nils
∂17-Jan-89 1840 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: Urgent: announcement of panel on funding
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Jan 89 18:40:49 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA18720; Tue, 17 Jan 89 18:40:05 PDT
Message-Id: <8901180240.AA18720@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 17 Jan 89 18:39:13 PST
Received: by BYUADMIN (Mailer R2.01A) id 0528; Tue, 17 Jan 89 19:38:34 MST
Date: Tue, 17 Jan 89 21:27:27 EST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Joseph Traub <traub@CS.COLUMBIA.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
From: Joseph Traub <traub@CS.COLUMBIA.EDU>
Subject: Re: Urgent: announcement of panel on funding
Comments: To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@CUVMB.CC.columbia.edu>,
simons@IBM.COM
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
In-Reply-To: Your message of Tue, 10 Jan 89 15:47:40 PST
Barbara: Thats quite a panel you've put together. I'm delighted to see your
interest in science policy.
I chair the Computer Science and Technology board of the National Academies
of Science and Engineering. We do studies on computer issues of national
importance. If ou'll send me your snailmail address I'll send you a couple of
our studies. Studies and workshops in progress include Computer Security,
Intellectual Property Protection, Competitiveness, and Software.
Incidentally, one of our studies deals with funding issues although we are
intentionally soft on the numbers. Joe
∂18-Jan-89 0049 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Prosser & Winkel : A joke or what....???
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Jan 89 00:49:45 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 18 Jan 89 00:47:16-PST
Message-ID: <LbPyE@SAIL.Stanford.EDU>
Date: 18 Jan 89 0048 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Prosser & Winkel : A joke or what....???
To: faculty@SCORE.STANFORD.EDU
∂16-Jan-89 1905 @Score.Stanford.EDU,@polya.Stanford.EDU:postmaster@score.stanford.edu Prosser & Winkel : A joke or what....???
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Jan 89 19:05:32 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 16 Jan 89 19:04:04-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA23229; Mon, 16 Jan 89 19:05:00 PDT
Date: 17 Jan 89 03:04:53 GMT
From: arul@polya.Stanford.EDU (Arul A. Menezes)
Organization: Stanford University
Subject: Prosser & Winkel : A joke or what....???
Message-Id: <6152@polya.Stanford.EDU>
Sender: postmaster@score.stanford.edu
To: csd@score.stanford.edu
"Perhaps we can sum up good design philosophy in a single phrase:
common courtesy. Consider the users and maintainers of your
system, and ask yourself what they will need in order to deal
efficiently with your creation. Let courtesy be your guide."
-The Art of Digital Design
Prosser and Winkel
Chapter 5
So what does that one solitary chapter in a 50 buck book
tell us anyway?? Maybe a few books on etiquette should have been
included in tha reading list. Those books mama used to teach us
table-manners out of.....
There is something distinctly brain-damaged about the
entire comp. process.
arul
∂18-Jan-89 0054 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: SITN
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Jan 89 00:54:24 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 18 Jan 89 00:47:39-PST
Message-ID: <LbPya@SAIL.Stanford.EDU>
Date: 18 Jan 89 0048 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Re: SITN
To: faculty@SCORE.STANFORD.EDU
∂17-Jan-89 1125 @Score.Stanford.EDU,@polya.Stanford.EDU:postmaster@score.stanford.edu Re: SITN
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Jan 89 11:24:50 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 17 Jan 89 11:23:15-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA18114; Tue, 17 Jan 89 11:24:10 PDT
Date: 17 Jan 89 19:23:57 GMT
From: jacobs@polya.Stanford.EDU (Joseph Jacobs)
Organization: Stanford University
Subject: Re: SITN
Message-Id: <6158@polya.Stanford.EDU>
References: <10$ti7@SAIL.Stanford.EDU>, <8901162032.AA04335@arisia.Xerox.COM>
Sender: postmaster@score.stanford.edu
To: csd@score.stanford.edu
I won't argue the claim that professors may know more about what sorts
of teaching methods are generally more effective, but I will argue
that different methods have different effects for different people.
Some people learn well by reading the material from a book. Others
have to have a visual/vocal presentation of the material before
anything sticks--it doesn't matter how many times they read the book.
Surely, there is an analagous situation here. Some people will learn
better live; for some people it won't make any difference; for others
they will learn better watching the tape because they can stop and
re-play something or re-view the entire presentation. If the various
methods are all available, then the student can choose the one which
is the most effective for him.
Having come from an undergraduate school which had nothing of
this sort, the televised approach was completely new to me. I liked
it immediately because the instructor could use pad and pen rather
than a chalkboard. The writing was in general more legible, faster,
equally visible from throughout the room, and could be prepared ahead
of time. I developed an immediate dislike for having to take classes
in Terman Auditorium because the instructor either tried to use a pad
at the podium (inappropriate because of facilities) or had to use the
chalkboard. Admittedly, there have been times in courses when I was
frustrated by the camera people focusing on the wrong thing or by an
instructor who flies through prepared slides a little too fast, but I
like this approach much more than a straight classroom/chalkboard
approach.
Joseph
∂18-Jan-89 0100 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: broadcasting classes
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Jan 89 01:00:17 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 18 Jan 89 00:47:49-PST
Message-ID: <LbPyk@SAIL.Stanford.EDU>
Date: 18 Jan 89 0048 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Re: broadcasting classes
To: faculty@SCORE.STANFORD.EDU
∂17-Jan-89 1204 @Score.Stanford.EDU,@polya.Stanford.EDU:postmaster@score.stanford.edu Re: broadcasting classes
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Jan 89 12:04:01 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 17 Jan 89 12:02:31-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA20588; Tue, 17 Jan 89 12:03:23 PDT
Date: 17 Jan 89 20:03:06 GMT
From: mkatz@Sesame.Stanford.EDU (Morris Katz)
Organization: Stanford University
Subject: Re: broadcasting classes
Message-Id: <6159@polya.Stanford.EDU>
References: <8901132255.AA04345@polya.Stanford.EDU>, <6096@polya.Stanford.EDU>
Sender: postmaster@score.stanford.edu
To: csd@score.stanford.edu
I personally believe that the quality of education for the students who chose
to attend classes is of paramount importance, so that only nonintrusive means
of televising courses should be accepted. This means that the instructor
should be allowed to use an overhead projector, blackboard, etc., at his/her
discretion. The instructor should not have to use a microphone, and the
students should not have to ask questions through microphones. Instead, the
classrooms should be equipt with the necessary microphones to pick up what the
participants are saying, and enough cameras should be running to pick up both
the instructor and the visual aids. The results of the multiple cameras can
then be fed to video land in a split screen format. Granted, the results would
probably not be quite as good as they currently are for video participants, and
High Resolution TV would probably be required for acceptable split screen
resolution; but, the educational experience for those in the classroom would be
greatly enhanced. In my experience, the current video setups adversely effect
the lecturers ability to communicate effectively to those in the room and make
asking questions more difficult, hampering the free exchange of information.
It is hard enough to get students to ask questions without requiring them to
talk into a microphone and piping their questions to the world.
Lastly, it was brought up that Stanford makes a lot of money off of video
courses. Lets not forget that they also get a lot of tuition from the students
in the room.
--
--
∂18-Jan-89 0102 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: SITN
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Jan 89 01:02:52 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 18 Jan 89 00:47:59-PST
Message-ID: <LbPyo@SAIL.Stanford.EDU>
Date: 18 Jan 89 0049 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Re: SITN
To: faculty@SCORE.STANFORD.EDU
∂17-Jan-89 1315 @Score.Stanford.EDU,@polya.Stanford.EDU:postmaster@score.stanford.edu Re: SITN
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Jan 89 13:11:10 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 17 Jan 89 13:09:32-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA25059; Tue, 17 Jan 89 13:10:29 PDT
Date: 17 Jan 89 21:10:16 GMT
From: bthomas@polya.Stanford.EDU (Becky Thomas)
Organization: Stanford University
Subject: Re: SITN
Message-Id: <6161@polya.Stanford.EDU>
References: <10$ti7@SAIL.Stanford.EDU>, <8901162032.AA04335@arisia.Xerox.COM>, <6158@polya.Stanford.EDU>
Sender: postmaster@score.stanford.edu
To: csd@score.stanford.edu
One of the more popular arguments to be made against televising classes seems
to be, "students learn better when they attend live lectures." I agree with
Joseph Jacobs that this is not true for every student (or for every class).
Perhaps, as David Dill says, students don't always know what's best for them;
but certainly no one thing is best for every student. Personally, I hate very
interactive classes unless they're extremely well-taught (kudos to Don Knuth
here); I may go hide in the overflow room, but that doesn't mean I'm not
paying attention.
I realize the question of who owns the rights to the tapes is an important
one. The tapes are an enormous convenience for students who miss a lecture,
and I'd like to continue to be able to go use them in the library on occasion.
Please realize, though, that students (even undergrads!) often *do* know what
works best for us, and we appreciate having options.
--
Becky Thomas
bthomas@polya.stanford.edu
∂18-Jan-89 0106 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: SITN
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Jan 89 01:05:57 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 18 Jan 89 00:48:01-PST
Message-ID: <xbPz7@SAIL.Stanford.EDU>
Date: 18 Jan 89 0049 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Re: SITN
To: faculty@SCORE.STANFORD.EDU
∂17-Jan-89 1737 @Score.Stanford.EDU,@polya.Stanford.EDU:postmaster@score.stanford.edu Re: SITN
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Jan 89 17:36:57 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 17 Jan 89 17:35:27-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA14887; Tue, 17 Jan 89 17:36:24 PDT
Date: 18 Jan 89 01:36:13 GMT
From: roland@polya.Stanford.EDU (Roland Conybeare)
Organization: Stanford University
Subject: Re: SITN
Message-Id: <6175@polya.Stanford.EDU>
References: <8901162032.AA04335@arisia.Xerox.COM>, <6158@polya.Stanford.EDU>, <6161@polya.Stanford.EDU>
Sender: postmaster@score.stanford.edu
To: csd@score.stanford.edu
Last quarter, I watched Hennessey's architecture course at home while
eating lunch or doing housework such as washing dishes. I do not think
my attention suffered at all. On the other hand, I was not taking the
course and in any case the televising was discontinued halfway through the
quarter.
For someone with a peripheral (that is to say comprehensive :-) interest
in a course I think TV lectures at home are valuable. Of course, such
students shouldn't expect to fall in the center of the teacher's
attention, either.
Roland Conybeare
∂18-Jan-89 0108 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU The best lectures I ever attended
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Jan 89 01:08:39 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 18 Jan 89 00:48:12-PST
Message-ID: <xbPzt@SAIL.Stanford.EDU>
Date: 18 Jan 89 0049 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: The best lectures I ever attended
To: faculty@SCORE.STANFORD.EDU
∂17-Jan-89 2048 @Score.Stanford.EDU,@polya.Stanford.EDU:postmaster@score.stanford.edu The best lectures I ever attended
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Jan 89 20:48:41 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 17 Jan 89 20:47:14-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA22567; Tue, 17 Jan 89 20:48:12 PDT
Date: 18 Jan 89 04:48:01 GMT
From: larrabee@polya.Stanford.EDU (Tracy Larrabee)
Organization: Stanford University
Subject: The best lectures I ever attended
Message-Id: <6180@polya.Stanford.EDU>
Sender: postmaster@score.stanford.edu
To: csd@score.stanford.edu
The very best lectures I ever attended at stanford were televised
courses. Zohar Manna, Brian Reid, John Hennessy, and Don Knuth give
televised lectures that make wonderful use of the overhead camera. I
took courses from each of these professors, and I saw each of their
lectures from a remote TV as well as in person. In each case, an
excellent remote class was an artifact of an even better local class.
There are always facial expressions, color graphics, unrepeated snide
comments, and the faces of fellow students that remote students miss
(it can be so reassuring to know that your fellow students look as
blank as you do). I don't think I was alone in figuring out that the
main class room was preferred: the main rooms were always packed when
the overflow rooms were not.
My personal opinion is that I would like all lectures to be given with
the aid of an overhead-camera, even when the class is not televised. I
think lecturers should have some control over the broadcast of their
lectures.
∂18-Jan-89 0111 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Televised Classes
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Jan 89 01:11:08 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 18 Jan 89 00:48:16-PST
Message-ID: <LbPzD@SAIL.Stanford.EDU>
Date: 18 Jan 89 0049 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Televised Classes
To: faculty@SCORE.STANFORD.EDU
∂17-Jan-89 2155 @Score.Stanford.EDU,@polya.Stanford.EDU:postmaster@score.stanford.edu Televised Classes
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Jan 89 21:55:21 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 17 Jan 89 21:53:53-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA25828; Tue, 17 Jan 89 21:54:52 PDT
Date: 18 Jan 89 05:54:42 GMT
From: rossner@polya.Stanford.EDU (Marc D. Rossner)
Organization: Stanford University
Subject: Televised Classes
Message-Id: <6181@polya.Stanford.EDU>
Sender: postmaster@score.stanford.edu
To: csd@score.stanford.edu
Time for the master's students to enter the fray. I know that I'm not
speaking only for myself when I say I think that the televised courses
are in general highly obnoxious. I attend nearly 100% of the lectures
live and am always distracted by the damned flickering screens. What's
worse is professors who gear their lectures toward the televised format,
i.e. conducting the entire class by presenting notes on the overhead
camera. At first I thought I needed to adjust my personal sleeping
habits when I found myself unable to EVER stay awake through a
certain long televised class last semester, but soon noticed that
nearly half (this is NOT an exaggeration) of the "studio-audience"
was literally sound asleep by the middle of each lecture because
of the soporific lecturing style which is encouraged by the televised
format.
I agree 100% with David Dill about the value of interaction in live
lectures. I personally hold "a priori" in higher regard classes like
his own in which the lecturers
still insist on using the blackboard so that the concepts
being presented can unfold naturally during the lecture instead of
being shoved on a piece of paper underneath the camera. Sorry, Tracy
Larrabee (or is that one 'r' and two 'b's?), but I think many of us
think the overhead camera has only a very negative effect on the classroom.
When I want to numerical analysis class last semester I came out
of almost every lecture not understanding in the least what the
professor had been trying to get at. Yet (in a sick sort of way)
I enjoyed going to this class as it was my only non-televised one -- just
your old fashioned 30 people, a classroom, a blackboard, and a
pleasant if befuddling professor.
So much for a student's opinion of SITN itself. As for the other
issue, I find criticism of the live broadcast, dorm viewing, etc
of televised classes somewhat hypocritical -- this department is
offering its students, for the University's own monetary gain, an
inferior environment for learning and is now complaining that some
students want to take advantage of all of this environment's side
effects. The criticism should be leveled at the televised classroom itself.
Marc Rossner
(are TV students permitted to dress like that at work, also?)
∂18-Jan-89 0720 @polya.Stanford.EDU:Ekaterini.Yannoulis@pulsar.fac.cs.cmu.edu Undeliverable mail
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Jan 89 07:20:40 PST
Received: from PULSAR.FAC.CS.CMU.EDU by polya.Stanford.EDU (5.59/25-eef) id AA04155; Wed, 18 Jan 89 07:20:04 PDT
Received: from PULSAR.FAC.CS.CMU.EDU by PULSAR.FAC.CS.CMU.EDU; 18 Jan 89 10:18:35 EST
From: Gripe@fac.cs.cmu.edu
Reply-To: Gripe@fac.cs.cmu.edu
To: aflb-tn@polya.stanford.edu
Subject: Undeliverable mail
Date: Wed, 18 Jan 89 10:18:28 EST
Message-Id: <28774.601139908@PULSAR.FAC.CS.CMU.EDU>
Sender: Ekaterini.Yannoulis@PULSAR.FAC.CS.CMU.EDU
------- Forwarded Message
Return-Path: <@C.CS.CMU.EDU:Gripe@FAC.CS.CMU.EDU>
Received: from C.CS.CMU.EDU by VEGA.FAC.CS.CMU.EDU; 16 Jan 89 17:05:16 EST
Date: Mon, 16 Jan 89 17:02:30 EDT
From: MAILER-DAEMON@c.cs.cmu.edu
Reply-To: Gripe@FAC.CS.CMU.EDU
To: MAILER-DAEMON@c.cs.cmu.edu
Subject: Undeliverable mail
Mail addressed to THEORYNT@NDSUVM1.BITNET@forsythe.stanford.edu@polya.Stanford.EDU@Score.Stanford.EDU at gsb-why.stanford.edu could not be sent.
- --------- Host gsb-why.stanford.edu transcript -----------
220-GSB-WHY.Stanford.EDU SMTP Service 6.1(221) at Mon 16 Jan 89 14:02:13-PST
220 Bugs/Gripes to Bug-MAISER@SIMTEL20.ARPA
HELO C.CS.CMU.EDU
250 GSB-WHY.Stanford.EDU - Hello, C.CS.CMU.EDU.#Internet
MAIL From:<MAILER-DAEMON@c.cs.cmu.edu>
250 MAIL accepted
RCPT To:<@gsb-why.stanford.edu,@Score.Stanford.EDU,@polya.Stanford.EDU,@forsythe.stanford.edu:THEORYNT@NDSUVM1.BITNET>
550 Host name "NDSUVM1.BITNET" unknown, recipient rejected
- ------- Message contents appear below ------
Date: Mon, 16 Jan 89 17:01:57 EST
From: MAILER-DAEMON@C.CS.CMU.EDU
To: THEORYNT@NDSUVM1.BITNET@forsythe.stanford.edu@polya.Stanford.EDU@Score.Stanford.EDU@GSB-WHY.STANFORD.EDU
Subject: Unable to deliver mail
----- Transcript of session follows -----
Unbalanced `>'
----- Unsent message follows -----
Received: from GSB-WHY.STANFORD.EDU by C.CS.CMU.EDU; 16 Jan 89 17:01:55 EST
Received: from Score.Stanford.EDU by GSB-WHY.Stanford.EDU with TCP; Mon 16 Jan 89 14:01:53-PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 16 Jan 89 14:01:10-PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA08207; Mon, 16 Jan 89 14:01:38 PDT
Message-Id: <8901162201.AA08207@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Mon, 16 Jan 89 14:00:27 PST
Received: by BYUADMIN (Mailer R2.01A) id 6405; Mon, 16 Jan 89 13:13:06 MST
Date: Mon, 16 Jan 89 10:28:14 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
gadi RSMA309@HAIFAUVM.BITNETAIFAUVM>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: gadi moran <RSMA309%HAIFAUVM.BITNET@forsythe.stanford.edu>
Subject: Faculty positions at University of Haifa
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
UNIVERSITY OF HAIFA
DEPARTMENT OF MATHEMATICS AND COMPUTER SCIENCE
APPLICATIONS ARE INVITED FOR ANTICIPATED FACULTY POSITION IN ALL AREAS OF
COMPUTER SCIENCE. THE DEPARTMENT WISHES TO STRENGTHEN ITS PROGRAMS THAT
COMBINE MATHEMATICS AND COMPUTER SCIENCE. STRONG INTEREST IN BOTH
RESEARCH AND TEACHING ARE EXPECTED. SEND RESUMEE INCLUDING RESEARCH
INTERESTS, LIST OF PUBLICATIONS AND ASK FOR 3 REFERENCE LETTERSSENT TO:
PROFESSOR YAIR CENSOR, CHAIRMAN
DEPARTMENT OF MATHEMATICS AND COMPUTER SCIENCE
UNIVERSITY OF HAIFA
HAIFA 31999
ISRAEL.
Bitnet: rsma403@haifauvm
------- End of Forwarded Message
∂18-Jan-89 1035 @Score.Stanford.EDU:coraki!pratt@Sun.COM TV
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Jan 89 10:35:33 PST
Received: from Sun.COM by SCORE.STANFORD.EDU with TCP; Wed 18 Jan 89 10:33:00-PST
Received: from sun.Sun.COM (sun-bb.sun.com) by Sun.COM (4.1/SMI-4.0)
id AA18760; Wed, 18 Jan 89 10:35:42 PST
Received: from coraki.UUCP by sun.Sun.COM (4.0/SMI-4.0)
id AA03089; Wed, 18 Jan 89 10:33:06 PST
Received: by (4.0/SMI-4.0Beta)
id AA00722; Wed, 18 Jan 89 10:32:31 PST
Date: Wed, 18 Jan 89 10:32:31 PST
From: Vaughan Pratt <coraki!pratt@Sun.COM>
Message-Id: <8901181832.AA00722@>
To: faculty@score.stanford.edu
Subject: TV
There are four cases: {teacher,student} {likes,hates} TV. All four
cases are represented. If you didn't know that before the recent
flurry of email on this topic you do now.
I'd like to see this information refined in two directions. For each
of teachers and students, what fraction likes TV? And what are the
main reasons people cite for their preferences?
What I would not be interested in, at least on this mailing list, is
the raw data from which we are expected to compute this ourselves.
-v
∂18-Jan-89 1114 aaai@sumex-aim.stanford.edu CMU Email Interface
Received: from sumex-aim.stanford.edu by SAIL.Stanford.EDU with TCP; 18 Jan 89 11:14:49 PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA06217; Wed, 18 Jan 89 11:13:14 PST
Date: Wed, 18 Jan 1989 11:13:13 PST
From: AAAI <aaai@sumex-aim.stanford.edu>
To: officers:;@sumex-aim.stanford.edu
Cc: aaai@sumex-aim.stanford.edu
Subject: CMU Email Interface
Message-Id: <CMM.0.88.601153993.aaai@sumex-aim.stanford.edu>
Below are the instructions for the use of the email interface to
the AI database at CMU. Please send your bug reports to
Greg Diskin at CMu (his net address is in the help document).
-Claudia
Message 80 (13303 chars)
Return-Path: <@po5.andrew.cmu.edu:diskin+@andrew.cmu.edu>
Received: from po5.andrew.cmu.edu by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA21735; Mon, 19 Dec 88 20:03:10 PST
Received: by po5.andrew.cmu.edu (5.54/3.15) id <AA00739> for aaai@sumex-aim.stanford.edu; MonQXfR0ny00Vs1A10UFr>;
Mon, 19 Dec 88 22:59:50 -0500 (EST)
Received: from rouzerville.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/usr1/diskin/.Outgoing/QF.rouzerville.andrew.cmu.edu.23ad713e.e3b9cb>;
Mon, 19 Dec 88 16:14:39 -0500 (EST)
Received: from Version.6.20.N.CUILIB.3.44.SNAP.NOT.LINKED.rouzerville.andrew.cmu.edu.rt.r3
via MS.5.5.rouzerville.andrew.cmu.edu.rt_r3;
Mon, 19 Dec 88 16:14:36 -0500 (EST)
Message-Id: <QXfL4xy00WEDA9mkIf@andrew.cmu.edu>
Date: Mon, 19 Dec 88 16:14:37 -0500 (EST)
From: "Gregory M. Diskin" <diskin+@andrew.cmu.edu>
X-Andrew-Message-Size: 12073+0
To: aaai@sumex-aim.stanford.edu
Subject: email interface
Cc: buchanan@tweety.cs.pittsburgh.edu,
"Mark H. Kibbey" <kibbey+@andrew.cmu.edu>
Claudia Mazzetti,
We are ready here for you to announce the availability of an email interface to
two databases:
1) Bruce Buchanan's bibliography of A.I. literature (currently 5,152
documents)
2) Carnegie Mellon University Libraries' technical report holdings
(currently 7,800 documents).
I have enclosed the help file for the interface at the end of this message.
Members can receive the help document by sending mail to AM77@VMA.CC.CMU.EDU.
The body of the message should consist of one line: HELP.
The mail server will run once daily (at night) to process incoming queries.
What is undecided at this point (as far as I know) is the mechanism for updatingBuchanan's file. Mark has agreed to maintain the database but I'm not sure whatthe procedure is for adding new records.
I'm also not sure how I should verify the authenticity of an AAAI id number,
which Mark has specified as a necessary command in messages which contain
queries.
I'll be happy to provide any more information about the system, if I've
overlooked anything.
Thanks,
Gregg Diskin
************************************************************************
* *
* AAAI INFORMATION SERVER *
* HELP DOCUMENT *
* *
************************************************************************
GENERAL INFORMATION
The AAAI Information Retrieval Service reads commands from the body of
an electronic mail message and returns the results to the sender. Com-
mands are typically database queries combining keywords and optional
∂18-Jan-89 1116 @Score.Stanford.EDU:jwilson@jaguar.Stanford.EDU NeXT machine installed near MJH 246
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Jan 89 11:16:10 PST
Received: from jaguar.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 18 Jan 89 11:13:25-PST
Received: by jaguar.Stanford.EDU (5.51/inc-1.01)
id AA03431; Wed, 18 Jan 89 11:15:34 PST
Date: Wed, 18 Jan 89 11:15:34 PST
From: James Wilson <jwilson@jaguar.Stanford.EDU>
Message-Id: <8901181915.AA03431@jaguar.Stanford.EDU>
To: faculty@score.stanford.edu, csd@score.stanford.edu
Subject: NeXT machine installed near MJH 246
A NeXT machine has been installed for evaluation use outside of MJH 246.
This machine may only be used by CSD and CSD-related faculty, staff, and students.
Faculty have priority over staff and students for using this machine.
James
∂18-Jan-89 1216 misha@polya.Stanford.EDU Correction on TODAY'S talk by bernd Sturmfels
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Jan 89 12:16:27 PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA18424; Wed, 18 Jan 89 12:13:36 PDT
Date: Wed, 18 Jan 89 12:13:36 PDT
From: Michael Kharitonov <misha@polya.Stanford.EDU>
Message-Id: <8901182013.AA18424@polya.Stanford.EDU>
To: aflb-all@polya.Stanford.EDU
Subject: Correction on TODAY'S talk by bernd Sturmfels
The talk is TODAY at 4:15, not 3:15, in the Math department.
Tea/coffee starts at 2:30.
Sorry for the confusion.
Misha
∂18-Jan-89 1227 LOGMTC-mailer seminar on lambda calculus and PL semantics
Received: from ra.stanford.edu by SAIL.Stanford.EDU with TCP; 18 Jan 89 12:27:24 PST
Received: by ra.stanford.edu (5.59/25-eef) id AA08277; Wed, 18 Jan 89 12:26:18 PDT
Date: Wed, 18 Jan 89 12:26:18 PDT
From: John Mitchell <jcm@ra.stanford.edu>
Message-Id: <8901182026.AA08277@ra.stanford.edu>
To: logmtc@sail
Subject: seminar on lambda calculus and PL semantics
This seminar will focus on fundamental theorems of
typed lambda calculus, semantics, polymorphism, and
applications to the study of programming languages.
One area of concentration will be the method of "logical
relations," which is used to prove almost all nontrivial
theorems about typed languages. (For example, the
"inclusive predicates" of Scott-Strachey semantics
are a special case.) Time permitting, we will also study
connections between typed languages and categorical
concepts. We will assume most of the material covered
in CS258. Notes will be available for those who did not
take CS 258 in the fall.
Organizational meeting: 4:15 PM, Thur 1/18, MJH 301
Send a preferred time via email if you cannot come
to this meeting.
∂18-Jan-89 1236 aaai@sumex-aim.stanford.edu trucated message
Received: from sumex-aim.stanford.edu by SAIL.Stanford.EDU with TCP; 18 Jan 89 12:36:38 PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA01703; Wed, 18 Jan 89 12:34:38 PST
Date: Wed, 18 Jan 1989 12:34:37 PST
From: AAAI <aaai@sumex-aim.stanford.edu>
To: officers:;@sumex-aim.stanford.edu
Cc: aaai@sumex-aim.stanford.edu
Subject: trucated message
Message-Id: <CMM.0.88.601158877.aaai@sumex-aim.stanford.edu>
We are having some problems with the file re: the CMU interface.
I hope to resend it to you later today.
Claudia
∂18-Jan-89 1252 LOGMTC-mailer seminar on lambda calculus and PL semantics
Received: from ra.stanford.edu by SAIL.Stanford.EDU with TCP; 18 Jan 89 12:52:49 PST
Received: by ra.stanford.edu (5.59/25-eef) id AA08322; Wed, 18 Jan 89 12:51:40 PDT
Date: Wed, 18 Jan 89 12:51:40 PDT
From: John Mitchell <jcm@ra.stanford.edu>
Message-Id: <8901182051.AA08322@ra.stanford.edu>
To: csd@score, logmtc@sail, phd@score
Subject: seminar on lambda calculus and PL semantics
That's Thurs the 19-th. Sorry.
∂18-Jan-89 1323 aaai@sumex-aim.stanford.edu resending CMU interface info
Received: from sumex-aim.stanford.edu by SAIL.Stanford.EDU with TCP; 18 Jan 89 13:23:09 PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA03550; Wed, 18 Jan 89 13:21:38 PST
Date: Wed, 18 Jan 1989 13:21:37 PST
From: AAAI <aaai@sumex-aim.stanford.edu>
To: officers:;@sumex-aim.stanford.edu
Cc: aaai@sumex-aim.stanford.edu
Subject: resending CMU interface info
Message-Id: <CMM.0.88.601161697.aaai@sumex-aim.stanford.edu>
Here we go again.
Message 80 (13303 chars)
Return-Path: <@po5.andrew.cmu.edu:diskin+@andrew.cmu.edu>
Received: from po5.andrew.cmu.edu by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA21735; Mon, 19 Dec 88 20:03:10 PST
Received: by po5.andrew.cmu.edu (5.54/3.15) id <AA00739> for aaai@sumex-aim.stanford.edu; Mon, 19 Dec 88 23:01:28 EST
Received: via switchmail; Mon, 19 Dec 88 23:01:17 -0500 (EST)
Received: from po5.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/service/mailqs/q003/QF.QXfR0ny00Vs1A10UFr>;
Mon, 19 Dec 88 22:59:50 -0500 (EST)
Received: from rouzerville.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/usr1/diskin/.Outgoing/QF.rouzerville.andrew.cmu.edu.23ad713e.e3b9cb>;
Mon, 19 Dec 88 16:14:39 -0500 (EST)
Received: from Version.6.20.N.CUILIB.3.44.SNAP.NOT.LINKED.rouzerville.andrew.cmu.edu.rt.r3
via MS.5.5.rouzerville.andrew.cmu.edu.rt_r3;
Mon, 19 Dec 88 16:14:36 -0500 (EST)
Message-Id: <QXfL4xy00WEDA9mkIf@andrew.cmu.edu>
Date: Mon, 19 Dec 88 16:14:37 -0500 (EST)
From: "Gregory M. Diskin" <diskin+@andrew.cmu.edu>
X-Andrew-Message-Size: 12073+0
To: aaai@sumex-aim.stanford.edu
Subject: email interface
Cc: buchanan@tweety.cs.pittsburgh.edu,
"Mark H. Kibbey" <kibbey+@andrew.cmu.edu>
Claudia Mazzetti,
We are ready here for you to announce the availability of an email interface to
two databases:
1) Bruce Buchanan's bibliography of A.I. literature (currently 5,152
documents)
2) Carnegie Mellon University Libraries' technical report holdings
(currently 7,800 documents).
I have enclosed the help file for the interface at the end of this message.
Members can receive the help document by sending mail to AM77@VMA.CC.CMU.EDU.
The body of the message should consist of one line: HELP.
The mail server will run once daily (at night) to process incoming queries.
What is undecided at this point (as far as I know) is the mechanism for updatingBuchanan's file. Mark has agreed to maintain the database but I'm not sure whatthe procedure is for adding new records.
I'm also not sure how I should verify the authenticity of an AAAI id number,
which Mark has specified as a necessary command in messages which contain
queries.
I'll be happy to provide any more information about the system, if I've
overlooked anything.
Thanks,
Gregg Diskin
************************************************************************
* *
* AAAI INFORMATION SERVER *
* HELP DOCUMENT *
* *
************************************************************************
GENERAL INFORMATION
The AAAI Information Retrieval Service reads commands from the body of
an electronic mail message and returns the results to the sender. Com-
mands are typically database queries combining keywords and optional
boolean or proximity operators (discussed later in this document).
The server replies with the set of bibliographic records which match the
query. The address of the Service is AM77@VMA.CC.CMU.EDU.
COMMANDS
The number of keywords and operators in a command line is optional, so
long as the number of characters in a line are not more than 80. Each
line of the message should contain one command. You may send as many as
twenty commands in a message. The system will ignore everything after
line twenty in the body of the message. It will also ignore the subject
heading. You can type anything you want there or leave it blank.
The system is indifferent to case; everything is converted to upper case
before it's parsed.
The easiest message to send (and you have presumably sent it to get
this help file) is a one-line message: HELP.
Unless you are asking for HELP, one line in your message must contain
your AAAI id-number. All you need to do is start a line with the com-
mand ID and then enter your id-number as in:
ID 123456
The most common messages contain lines beginning with the command FIND.
This is the command used to specify a query, as in:
FIND boolean adj (arithmetic or logic)
FIND NATURAL-LANGUAGE PARSING
Since FIND is the most common command it's the default when a line begins
with a keyword rather than a command, as in:
boolean adj (arithmetic or logic)
NATURAL-LANGUAGE PARSING
In alphabetical order the commands are:
COMMAND PARAMETERS DESCRIPTION
_______ __________ ___________
BASE name The BASE command specifies the database
to be searched in subsequent queries
(up to the next BASE command). The
default database is BUCH, Buchanan's
Artificial Intelligence Bibliography.
A list of valid database names and
definitions is given in table III.
FIND search statement The FIND command specifies the keywords,
operators, and field names which comprise
the search statement or query. Table I
lists operators; Table II lists common
field names. Note: FIND is the default
command when a command line begins with
a keyword.
FORMAT spec The FORMAT command specifies the output
format desired. The default is "A" for
all paragraphs. The alternative format
currently defined is "B" to list just
authors and titles in the output file.
A FORMAT statement applies to all follow- ing queries until another FORMAT
statement occurs.
HELP A HELP request will cause the HELP file
to be mailed. No other command is
honored in a message containing a HELP
request.
ID id-number Messages (excepting HELP requests) must
contain the sender's AAAI identification
number. There is no default. Queries
submitted without an ID line or with-
out a valid id number are not searched,
but an error message is returned.
MSG text A MSG command will cause succeeding
line(s) of text to be forwarded to the
system maintainer. A response will be
sent as soon as possible. No other
commands are honored in a message con-
taining a MSG command.
PATH return path A PATH command specifies the return path
to be used as the mail address for the
message reply. It overrides the userid-
path in the message's "From:" field.
RANGE from,to The RANGE command specifies the start and
ending document numbers to be returned in
the output. It applies only to the query
which immediately follows on the next
line. This command should be used when
an earlier message query generated so
many hits that the line limit
of 2000 lines was exceeded. You can get
subsequent records by specifying a range
beginning with the next sequential record.
For example:
RANGE 51,100
FIND ARTIFICIAL-INTELLIGENCE
TABLE I. OPERATORS
ADJ The ADJ operator specifies keywords which must appear
together in the document in the order given. A number n
between 1 and 7 may be added to the operator, e.g.,
ADJ3, to signify that no more than n keywords may separate
the two specified words. For example:
FIND finite adj state
FIND FINITE ADJ1 AUTOMATA
AND The AND operator occurring between two keywords means
both words must be present in the record or document. AND
is the default operator when no operator occurs between
keywords. Here are two examples:
FIND COMPUTATION AND DEDUCTION
FIND NEWELL SIMON PROBLEM ADJ SOLVING
NEAR The same as the ADJ operator, except the keywords may
occur in either order.
NOT The NOT operator excludes documents from the result set.
For example, the query FIND PROCESS NOT CONTROL
retrieves documents which contain the keyword PROCESS as
long as they don't contain the keyword CONTROL.
SAME The SAME operator specifies documents which have both
keywords in the same field. (Fields are named paragraphs,
such as the author field or the title field). For
example:
FIND LISP SAME TUTOR
WITH The WITH operator is even more specific than SAME -- it
specifies documents with the bracketing keywords in the
same sentence. For example:
FIND SIMULATION WITH MODEL
- The '-' operator occurring between two keywords means
the first keyword immediately precedes the second in some
field in the document. As such, it's equivalent to the
ADJ operator. For example:
FIND PARALLEL-PROCESSING
HEURISTICS AND FORMAL-SYSTEMS
$ The '$' operator is a suffix operator. When attached to
a word stem it matches all words beginning with the stem.
For example, SIMULAT$ will match SIMULATE, SIMULATES,
SIMULATION, SIMULATIONS, SIMULATING, etc.
TABLE II. FIELDS
/TI Title field
/AU Author field
/SU Subject field
Specifying the field a keyword should be found in is some-
times useful for limiting the output when the keyword occurs
frequently in the database. The search HEURISTICS/TI means
that HEURISTICS must occur in the title field of a document
for that document to be included in the result set.
The syntax for the field limit is keyword"/"field as is
evident in these examples:
FIND RECURSIVELY/TI
FIND SYSTEMS NEAR1 FORMAL/SU
TABLE III. DATABASES
The following is a list of database names and descrip-
tions. The names are the only valid parameters for the
BASE command.
BUCH Bruce Buchanan's bibliography of the artificial intelli-
gence literature. This is the default database.
CMUT Carnegie-Mellon University Libraries' technical report
holdings.
NOTES
1) Command sequence
The ordering of commands is occasionally important.
For example, the BASE command, which is used to specify a database
other than the default database, applies to all FOLLOWING queries, not
to any that preceded it. The same is true for the FORMAT command which
specifies the output form desired. Both of these commands are in effect
up to the next BASE or FORMAT entry. However, the RANGE command applies
only to the next query. After that the default RANGE command goes into
effect, if there are more queries.
2) Replies
Each query in a message sent to the server will receive a separate
reply. If the results are a surprise or you get a cryptic error res-
ponse, use the MSG command to communicate with system maintainers.
3) System Limits
o A maximum of twenty lines are processed from the body of a
mail message. Remaining lines, if any, are ignored.
o Output from an individual query is cut off at 1000 lines. Use
the RANGE command in subsequent messages to get more output.
o Search sets created by prior queries in a message do not carry
over to successive queries. So a query in the form:
"FIND 1 and keyword" will not specify search set #1.
SAMPLES
*****************************************************************
From: GD07@VMA.CC.CMU.EDU
To: AM77@VMA.CC.CMU.EDU
Subject:
id 2345zz
format b
automata
*****************************************************************
From: "Gregory M. Diskin <diskin+@andrew.cmu.edu>
To: AM77@VMA.CC.CMU.EDU
Subject:
id 5555xyz
find finite-state
find formal adj system$
*****************************************************************
∂18-Jan-89 1457 @polya.Stanford.EDU:imielins@aramis.rutgers.edu PODS 89 - Final Program
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Jan 89 14:57:19 PST
Received: from MARCIN.RUTGERS.EDU by polya.Stanford.EDU (5.59/25-eef) id AA00268; Wed, 18 Jan 89 14:51:32 PDT
Received: by marcin.rutgers.edu (5.59/SMI4.0/RU1.1/3.03)
id AA00202; Wed, 18 Jan 89 17:50:35 EST
Date: Wed, 18 Jan 89 17:50:35 EST
From: imielins@aramis.rutgers.edu
Message-Id: <8901182250.AA00202@marcin.rutgers.edu>
To: nail@polya.stanford.edu
Subject: PODS 89 - Final Program
------------------------------------------------
Eights ACM SIGACT-SIGMOD-SIGART Symposium
on
PRINCIPLES OF DATABASE SYSTEMS
Philadelphia, Pennsylvania, March 29-31, 1989
INFORMATION
LOCATION
The 8th ACM Symposium on Principles of Database Systems will be held
at The Warwick, a four star hotel, situated in the heart of downtown
Philadelphia, within walking distance from first class restaurants,
concert halls, theaters and galleries. The Warwick Hotel,
a Historical Landmark, combines 19th-century atmosphere with
20th-century amenities.
Checkout and checkin time is noon;
A block of rooms has been reserved until March 6th, 1989.
Please reserve a room by using the form provided or by calling 800-523-4210
Room rates and availability are not guaranteed past March 6th.
REGISTRATION
Advanced registration is requested using the form provided.
Registration rates go up markedly after March 6th. A registration
desk will be open Tuesday night from 7:30pm to 10:00pm, and during the
day on Wednesday (8:30 am to 4:30 pm). Registrants, other than
students, receive admission to the technical sessions, one copy of the
proceedings, reception, lunch, and a banquet at the historical
Franklin Institute.
Student registration, available to full-time students only, includes
the technical sessions, reception and one copy of the proceedings.
Additional copies of the proceedings will be available for sale at
the registration desk.
TRANSPORTATION
There are two choices for ground transportation from the airport to the hotel.
The limousine service from the airport to major Philadelphia hotels including
Warwick is available for about 6 dollars/person. Additionally, taxi fare
to the hotel is about 25 dollars.
For participants driving to The Warwick, parking is available at
the rate 8.50/day at Penn Warwick lot on Chancellor and 17th street.
5 dollar/day rebate is provided for those participants who stay in the hotel.
CLIMATE
Normal daily temperatures in Philadelphia
in March range from 35 to 50 degrees F.
Occasional cold fronts bring northerly winds but snow is rare
at this time of the year.
EVENT LOCATION
All technical sessions, reception, lunch, and business meeting will be held
at The Warwick Hotel. On Thursday night there will be a reception
and banquet at the historical Franklin institute at 20th & the Parkway,
walking distance from the hotel.
TECHNICAL PROGRAM
TUESDAY, MARCH 28, 1989
Reception: 7:30 pm - 10:00 pm, Crystal Room
WEDNESDAY, MARCH 29, 1989
Note: All talks will take place in the Ballroom
TUTORIAL 1: 8:15 am - 9:15 am
Non-monotonic Reasoning,
Teodor C. Przymusinski (University of Texas at El Paso)
SESSION 1: 9:30 am - 10:40 am
Chair: Tomasz Imielinski (Rutgers University)
The Alternating Fixpoint of Logic Programs with Negation
Allen Van Gelder (University of California, Santa Cruz)
Every Logic Program has a Natural Stratification and an Iterated Fixed
Point Model, Teodor C. Przymusinski (University of Texas at El Paso)
A Procedural Semantics for Well Founded Negation in Logic Programs,
Kenneth A. Ross (Stanford University)
Coffee Break: 10:40 am - 11:15 am
SESSION 2: 11:15 am - 12:45 pm
Chair: Teodor C. Przymusinski (University of Texas at El Paso)
Logic Programming as Constructivism: A Formalization and its Application
to Databases, Francois Bry (ECRC, Munich)
Complexity of Query Processing in Databases with OR-Objects,
T. Imielinski and K. Vadaparty (Rutgers University)
A Sound and Complete Query Evaluation Algorithm for Relational Databases
with Disjunctive Information, Li Yan Yuan and Ding-An Chiang (University
of Alberta)
Horn Tables - An Efficient Tool for Handling Incomplete Information in
Databases, Gosta Grahne (University of Helsinki)
Lunch: 12:45 pm - 2:15 pm
SESSION 3: 2:15 pm - 3:45 pm
Chair: Carlo Zaniolo (MCC)
Invited Talk: Automata Theory for Database Theoreticians,
Moshe Y. Vardi (IBM Almaden Research Center)
Declarative Expression of Deductive Database Updates,
Sanjay Manchanda (University of Arizona)
Updating Databases in the Weak Instance Model,
Paolo Atzeni (Universita di Napoli and IASI-CNR) and Riccardo Torlone
(IASI-CNR)
Coffee Break: 3:45 pm - 4:15 pm
SESSION 4: 4:15 pm - 5:45 pm
Chair: Daniel J. Rosenkrantz (SUNY at Albany)
Attribute Agreement,
Y. C. Tay (National University of Singapore)
Can Constant-time-maintainability be More Practical?
Ke Wang (Chongqing University, PRC)
Practical Algorithms for Finding Prime Attributes and Testing Normal Forms,
Heikki Mannila (University of Helsinki) and Kari-Jouko Raiha (Univeristy
of Tampere)
A Decision Procedure for Conjunctive Query Disjointness,
Charles Elkan (Cornell University)
Business Meeting: 8:30 pm - 10:00 pm,
THURSDAY, MARCH 30, 1989
TUTORIAL 2: 8:15 am - 9:15 am
Recursive Query Processing,
Catriel Beeri (Hebrew University)
SESSION 5: 9:30 am - 10:40 am
Chair: Catriel Beeri (Hebrew University)
Bottom-up Beats Top-down for Datalog,
Jeffrey D. Ullman (Stanford University)
On the Power of Alexander Templates,
Hirohisa Seki (Institute for New Generation Computer Technology, Tokyo)
Safety of Datalog Queries over Infinite Databases,
Yehoshua Sagiv (Hebrew University) and Moshe Y. Vardi
(IBM Almaden Research Center)
Coffee Break: 10:40 am - 11:15 am
SESSION 6: 11:15 am - 12:45 pm
Chair: Michael Kifer (SUNY at Stony Brook)
Proof-tree Transformation Theorems and Their Applications,
Raghu Ramakrishnan (University of Wisconsin), Yehoshua Sagiv
(Hebrew University), Jeffrey D. Ullman (Stanford University), and
Moshe Y. Vardi (IBM Almaden Research Center)
Linearising Nonlinear Recursions in Polynomial Time,
Yatin P. Saraiya (Stanford University)
Inference of Monotonicity Constraints in Datalog Programs,
Alexander Brodsky and Yehoshua Sagiv (Hebrew University)
Why a Single Parallelization Strategy is Not Enough in Knowledge Bases,
Simona Cohen and Ouri Wolfson (Technion)
Lunch: 12:45 pm - 2:15 pm
SESSION 7: 2:15 pm - 3:45 pm
Chair: William E. Weihl (MIT)
Invited Talk: Modular Architectures for Distributed Database Systems,
Alfred Z. Spector (Carnegie-Mellon University)
Clustered Multiattribute Hash Files,
Doron Rotem (University of California, Berkeley)
Utilization of B-trees with Inserts, Deletes and Modifies,
Theodore Johnson and Dennis Shasha (New York University)
Coffee Break: 3:45 pm - 4:15 pm
SESSION 8: 4:15 pm - 5:30 pm
Chair: Hector Garcia-Molina (Princeton University)
Fractals for Secondary Key Retrieval,
Christos Faloutsos and Shari Roseman (University of Maryland, College Park)
Declustering Using Error Correcting Codes,
Christos Faloutsos and Dimitrios Metaxas (University of Maryland, College Park)
The Impact of Recovery on Concurrency Control,
William E. Weihl (MIT)
Concurrency Control for Nested Transactions Accessing B-trees,
Ada Fu and Tiko Kameda (Simon Fraser University)
Reception and Banquet at Franklin Institute, 6-10 pm.
FRIDAY, MARCH 31, 1989
TUTORIAL 3: 8:15-9:15
Expressive Power of Query Languages,
Victor Vianu (University of California, San Diego)
SESSION 9: 9:30 am - 10:40 am
Chair: Victor Vianu (University of California, San Diego)
Hypothetical Datalog with Stratification: Complexity and Expressibility,
Anthony J. Bonner (Rutgers University)
Inductive Pebble Games and the Expressive Power of Datalog,
V. S. Lakshmanan and A. O. Mendelzon (University of Toronto)
On the First-Order Expressibility of Recursive Queries,
Stavros S. Cosmadakis (IBM T.J. Watson Research Center)
Coffee Break: 10:40 am - 11:15 am
SESSION 10: 11:15 am - 12:45 pm
Chair: Ashok K. Chandra (IBM T.J. Watson Research Center)
Expressibility of Bounded-Arity Fixed-Point Query Hierarchies,
Pratul Dublish and S. N. Maheshwari (IIT Delhi)
Relational Database Behavior: Utilizing Relational Discrete Event Systems
and Models, Zvi M. Kedem and Alexander Tuzhilin (New York University)
Untyped Sets, Invention, and Computable Queries,
Richard Hull and Jianwen Su (University of Southern California)
Lunch: 12:45 pm - 2:15 pm
SESSION 11: 2:15 pm - 3:45 pm
Chair: Oded Shmueli (Technion)
Modeling Complex Structures in Object-Oriented Databases,
C. Lecluse and P. Richard (GIP Altair)
C-Logic of Complex Objects,
Weidong Chen and David S. Warren (SUNY at Stony Brook)
A Logic for Object-Oriented Logic Programming (Maier's O-Logic: Revisited),
Michael Kifer and James Wu (SUNY at Stony Brook)
Type Systems for Querying Class Hierarchies with Non-Strict Inheritance,
Alexander Borgida (Rutgers University)
-------------------------------------------------------------------------------
CONFERENCE ORGANIZATION
Sponsors: SIGACT, SIGMOD, and SIGART
Executive Committee: Ashok K. Chandra, Seymour Ginsburg,
Tomasz Imielinski, Avi Silberschatz,
Moshe Y. Vardi, Mihalis Yannakakis
Conference Chair: Avi Silberschatz, Dept. of Computer Sciences,
University of Texas at Austin, Austin, Texas 78712.
(512) 471-9706, avi@cs.utexas.edu
Program Chair: Ashok K. Chandra, IBM T.J. Watson Research Center
P.O. Box 218, Yorktown Heights, NY 10598.
(914) 945-1752, ashok@ibm.com (bitnet ASHOK@YKTVMV)
Local Arrangements Chair: Tomasz Imielinski, Dept. of Computer Science,
Rutgers University, New Brunswick, NJ 08903.
(201) 932-3551, imielinski@aramis.rutgers.edu
Program Committee: Catriel Beeri, Ashok K. Chandra, Hector Garcia-Molina,
Michael Kifer, Teodor C. Przymusinski, Daniel J. Rosenkrantz, Oded Shmueli,
Victor Vianu, William E. Weihl, Carlo Zaniolo.
ADVANCE REGISTRATION FORM, ACM-PODS
Please send this form or a facsimile along with a money order or check
(payable to 8th ACM SYMPOSIUM ON PRINCIPLES OF DATABASE SYSTEMS) to:
ACM-PODS Registration
c/o Carol Petty
Dept. of Computer Science
Rutgers University
New Brunswick, NJ 08903
(Before Mar. 6)(After)
ACM and SIG member $220 $285
ACM member only $230 $295
SIG member only $235 $300
Nonmember $285 $350
Student $ 50 $ 60
Requests for refunds will be honored until March 6, 1989.
Name_____________________________________________________________
Affiliation_________________________________________________________
City_____________________________State________________Zip__________
Country_____________________________Telephone______________________
Net Address________________________________________________________
_____ Check here if confirmation of registration is required.
Dietary restrictions: _______Kosher _______Vegetarian
HOTEL RESERVATION FORM, ACM-PODS March 1989
Please mail this form or a facsimile (being sure to mention the ACM-PODS
Conference) by March 6 to:
The Warwick Hotel,
17th at Locust Street
Philadelphia, PA 19103
Tel: (215) 735-6000
or (800) 523-4210
Accomodations desired:
_____Single $80
_____Double $90
Arrival date_____________________________________Time__________________________
Departure date___________________________________Time__________________________
Name_________________________________________________________________________
Sharing room with______________________________________________________________
Address________________________________________________________________________
City_______________________________State__________________Zip__________________
Country________________________________________________________________________
All rooms will be held until 4pm the day of arrival without deposit/guarantee.
For arrivals later than 4pm please guarantee to a major credit card:
_____Amer. Express _____VISA _____Mastercard _____Diners _____Discover
Credit Card number____________________________________________________________
Exp. Date___________________________________________________________________
Signature____________________________________________________________________
∂18-Jan-89 1537 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu SIGACT News Deadline
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Jan 89 15:37:04 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA03264; Wed, 18 Jan 89 15:36:18 PDT
Message-Id: <8901182336.AA03264@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Wed, 18 Jan 89 15:35:25 PST
Received: by BYUADMIN (Mailer R2.01A) id 7171; Wed, 18 Jan 89 16:35:03 MST
Date: Wed, 18 Jan 89 10:16:14 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Michael A. Langston" <langston@CS2.WSU.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Michael A. Langston" <langston@CS2.WSU.EDU>
Subject: SIGACT News Deadline
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
This is to remind potential contributors that the deadline for the next issue
of SIGACT News is imminent. Items received after February 1, 1989, will not
be published in the Winter 1989 issue.
Also, please note that a Transitions section has recently returned to the News.
(Refer to the Fall 1988 issue for details.) Send your input for this section
to me, preferably via email, marked for Transitions.
Mike Langston
langston@cs2.wsu.edu
(509) 335-6486
∂18-Jan-89 1823 emma@csli.Stanford.EDU CSLI Calendar, January 19, 4:12
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Jan 89 18:23:49 PST
Received: by csli.Stanford.EDU (4.0/inc-1.0)
id AA25101; Wed, 18 Jan 89 17:03:32 PST
Date: Wed, 18 Jan 89 17:03:32 PST
From: emma@csli.Stanford.EDU (Emma Pease)
Message-Id: <8901190103.AA25101@csli.Stanford.EDU>
To: friends@csli.Stanford.EDU
Subject: CSLI Calendar, January 19, 4:12
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
19 January 1989 Stanford Vol. 4, No. 12
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR NEXT THURSDAY, 26 January 1989
12 noon TINLunch
Cordura Hall Kazunori Ueda
Conference Room ICOT
3:30 p.m. Tea
Ventura Hall
____________
NEXT WEEK'S TINLUNCH
Kazunori Ueda
ICOT
January 26
Dr. Kazunori Ueda will talk on (the design principle of) his
concurrent logic programming language Guarded Horn Clause (GHC). The
talk will include how people who actually write application programs
feel, and Ueda's plan to refine GHC as a good logic programming
language, considering their response.
____________
LINGUISTICS DEPARTMENT COLLOQUIUM
Focusing on Phonological Phrases in Chichewa
Jonni M. Kanerva
Friday, 20 January, 3:15
Cordura Conference Room
From segment to word to phrase and beyond, each level of phonological
structure not only contains the forms of its parts but also adapts
their combination to that level's own patterns of form. The theory of
Prosodic Phonology is being developed as an explicit model of these
levels, their interrelationships, and their interactions with other
linguistic subsystems. In particular, the theory posits a hierarchy
of levels, two of which have received the majority of attention: the
intonational phrase (IP) and, one step down, the phonological phrase
(p-phrase). The IP is generally found to be a broad constituent,
often taking in an entire clause or more; its patterns of formation
show high variability with respect to syntactic constituent structure
and are sensitive to factors from semantics and discourse. The
p-phrase, on the other hand, is markedly smaller and is tightly
coupled to the syntax.
The evidence I present from Chichewa phrasal phonology presents a
rather different picture. Several lines of evidence converge to
locate IPs in Chichewa, yet much of the variability to be expected of
the IP occurs instead at the next level down. Prosodic constituents
at this level are medium-sized and, for a given syntactic structure,
may be formed into several alternate groupings. This indeterminacy
goes well beyond that allowed for p-phrases; it is resolved, though,
by taking into account the semantically and pragmatically motivated
feature focus. I conclude that, in order to maintain self-consistent
and meaningful prosodic levels, a new level in Prosodic Phonology, the
Focal Phrase, should be recognized between the IP and the p-phrase.
-----------
SYMBOLIC SYSTEMS FORUM
What Artificial Intelligence Is; What It Is Not
Stan Rosenschein
Computer Science and Teleos Research
Friday, 20 January, 3:15
Room 60:61J
Next week Peter Sells will speak on "Quantification in Natural
Language."
∂18-Jan-89 1842 @polya.Stanford.EDU:tah@linz MTC Seminar
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Jan 89 18:42:45 PST
Received: from linz.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA14726; Wed, 18 Jan 89 18:41:43 PDT
Received: by linz.stanford.edu (5.59/25-eef) id AA22935; Wed, 18 Jan 89 18:36:02 PDT
Message-Id: <8901190236.AA22935@linz.stanford.edu>
To: lop@polya
Subject: MTC Seminar
Cc: liz <eswolf@polya>, martin <martin@polya>, csd@score
Reply-To: tah@cs.stanford.edu
Date: 18 Jan 89 18:35:58 PST (Wed)
From: Tom Henzinger <tah@linz>
The MTC Seminar will, as announced last week, continue this quarter,
Fridays at noon in MJH 301.
The first meeting will be on January 20. Lacking a better idea, Liz,
Martin (hope you're reading this!), and I are going to summarize last
week's POPL (i.e., each of us picks her/his favorite paper and gives
a short presentation, OK?).
We will also decide on a topic for the following weeks. Since there
is already John's seminar on types and semantics, I would like to see
us concentrate on concurrency this quarter.
-- Tom.
∂19-Jan-89 0820 tcr@sumex-aim.stanford.edu IBM ARC CS Seminar
Received: from sumex-aim.stanford.edu by SAIL.Stanford.EDU with TCP; 19 Jan 89 08:20:44 PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA16061; Thu, 19 Jan 89 08:19:31 PST
Date: Thu, 19 Jan 1989 8:19:30 PST
From: TC Rindfleisch <tcr@sumex-aim.stanford.edu>
To: SSRG-Systems-Staff@sumex-aim.stanford.edu, AAP@sumex-aim.stanford.edu
Cc: Rindfleisch@sumex-aim.stanford.edu
Subject: IBM ARC CS Seminar
Message-Id: <CMM.0.88.601229970.tcr@sumex-aim.stanford.edu>
FYI re an IBM seminar of possible interest... Tom R.
---------------
IBM Almaden Research Center
650 Harry Road
San Jose, CA 95120-6099
CALENDAR
January 23 - 27, 1989
...
01/26 - PACKET ROUTING ALGORITHMS FOR FIXED-CONNECTION NETWORKS
T. Leighton, M.I.T.
Comp. Sci. Sem. Thurs., Jan. 26 1:00 P.M Room: Front Aud.
The development of efficient packet routing algorithms is a central
concern in the design of any large scale parallel computer. The reason
is obvious: it is important to get the right data to the right place
within a reasonable amount of time. For most parallel machines, the
data routing is performed on a well-structured network such as a
hypercube, butterfly or array. In the talk, we will survey the basic
techniques used for routing packets on such networks. In particular, we
will show how to solve any routing problem on these networks in near
optimal time using a randomized algorithm with combining.
The talk will be introductory in nature and represents recent joint work
with Bruce Maggs, Satish Rao and Abhiram Ranade.
Host: B. Simons
-----------------------------------------------------------------------
For further information on individual talks, please contact the host
listed above.
Visitors, please arrive 15 minutes early. IBM's Almaden Research
Center (ARC) is located adjacent to Santa Teresa County Park, between
Almaden Expressway and U.S. 101, about 10 miles south of Interstate
280. From U.S. 101, exit at Bernal Road, and follow Bernal Road west
past Santa Teresa Blvd. into the hills (ignoring the left turn for
Santa Teresa Park). Alternatively, follow Almaden Expressway to its
southern terminus, turn left onto Harry Road, then go right at the ARC
entrance (about a quarter of a mile later) and go up the hill. For
more detailed directions, please phone the ARC receptionist at (408)
927-1080.
IBM Almaden Research Center electronically distributes both its
complete calendar of seminars and a subset of Computer Science
seminars only. Send requests for inclusion in either electronic
mailing list to CALENDAR@IBM.COM (CALENDAR at ALMVMA on VNET or
BITNET), specifying either the complete calendar or the Computer
Science subset.
∂19-Jan-89 0835 HEMENWAY@Score.Stanford.EDU Need Someone for Orals Committee
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Jan 89 08:35:15 PST
Date: Thu 19 Jan 89 08:33:28-PST
From: Sharon Hemenway <HEMENWAY@Score.Stanford.EDU>
Subject: Need Someone for Orals Committee
To: ac@Score.Stanford.EDU
Reply-To: Hemenway@Score.Stanford.EDU
Message-ID: <12463817334.22.HEMENWAY@Score.Stanford.EDU>
I am seeking someone who is willing to serve as the fourth, "random"
member of Mary Holstege's Oral Examination committee. The exam is
scheduled for the afternoon of Tuesday, Feb. 21 (I do realize that
this is the same time as Arun Swami's exam but, apparently, there was
no alternative.). The title of Mary's dissertation is "Marking and
the Design of Notations" and her advisor is Terry Winograd.
I apologize for this global appeal but I have not been able to find
anyone by asking individually so I thought I'd try this route.
Many thanks--
Sharon
-------
∂19-Jan-89 0908 HEMENWAY@Score.Stanford.EDU Let the Games Begin!
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Jan 89 09:07:58 PST
Date: Thu 19 Jan 89 09:06:01-PST
From: Sharon Hemenway <HEMENWAY@Score.Stanford.EDU>
Subject: Let the Games Begin!
To: phd-adm@Score.Stanford.EDU
cc: nilsson@Score.Stanford.EDU, damon@Score.Stanford.EDU
Reply-To: Hemenway@Score.Stanford.EDU
Message-ID: <12463823261.22.HEMENWAY@Score.Stanford.EDU>
A hearty welcome to everyone on the PhD Admissions Committee! Your
"job" will only last about five weeks although there will be a lot to
do in that short period of time as we choose the 1989-90 entering
class.
We have scheduled the first meeting of the committee for 12 noon on
Thursday, Feb. 2 in MJH 252 (lunch to be provided). We anticipate
that we will begin distributing application folders on Friday, Feb. 3
so this meeting is quite important to discuss the procedures and
schedules that we will have to follow. We anticipate following last
year's schedule as closely as possible (largely because it worked
quite well). In rough outline, that means having four rounds of
readings between Feb. 3 and Feb. 17 with the Round 1 meeting around
Feb. 21. The round 2 readings would then take place between Feb. 22
and March 2 with the final meeting around March 6.
Please let me know if it is not possible for you to meet on Feb. 2
although I ask that you keep in mind that our tight time-table does
limit our scheduling possibilities. Also, please let me know right
away if you have any extended travel plans between Feb. 3 and March 10.
Thank you for your help.
Sharon
-------
∂19-Jan-89 1035 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu SIGACT News Deadline
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Jan 89 10:35:23 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA04375; Thu, 19 Jan 89 10:34:14 PDT
Message-Id: <8901191834.AA04375@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Thu, 19 Jan 89 10:33:21 PST
Received: by BYUADMIN (Mailer R2.01A) id 6746; Thu, 19 Jan 89 11:33:00 MST
Date: Thu, 19 Jan 89 12:04:30 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Michael A. Langston" <langston@CS2.WSU.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Michael A. Langston" <langston@CS2.WSU.EDU>
Subject: SIGACT News Deadline
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
This is to remind potential contributors that the deadline for the next issue
of SIGACT News is imminent. Items received after February 1, 1989, will not
be published in the Winter 1989 issue.
Also, please note that a Transitions section has recently returned to the News.
(Refer to the Fall 1988 issue for details.) Send your input for this section
to me, preferably via email, marked for Transitions.
Mike Langston
langston@cs2.wsu.edu
(509) 335-6486
∂19-Jan-89 1049 @Score.Stanford.EDU:chandler@polya.Stanford.EDU The case of the missing fedora.....
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Jan 89 10:49:22 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 19 Jan 89 10:46:04-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA05101; Thu, 19 Jan 89 10:47:03 PDT
Date: Thu, 19 Jan 1989 10:47:00 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score
Subject: The case of the missing fedora.....
Message-Id: <CMM.0.87.601238820.chandler@polya.stanford.edu>
Somebody left a brownish fedora at Nils' house on New Years Day. I have it
here in my office and Nils would love to reunite it with its owner. If it
belongs to you, or if you remember seeing someone wearing it, please let me know.
∂19-Jan-89 1126 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Last Call for Papers
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Jan 89 11:25:57 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA07410; Thu, 19 Jan 89 11:25:15 PDT
Message-Id: <8901191925.AA07410@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Thu, 19 Jan 89 11:24:20 PST
Received: by BYUADMIN (Mailer R2.01A) id 8231; Thu, 19 Jan 89 12:20:54 MST
Date: Thu, 19 Jan 89 12:09:05 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Kerny McLaughlin <kerny@CS.COLUMBIA.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Kerny McLaughlin <kerny@CS.COLUMBIA.EDU>
Subject: Last Call for Papers
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
LAST CALL FOR PAPERS
Third Symposium on Complexity of Approximately Solved Problems
Computer Science Department
Columbia University
April 3-5, 1989
PROGRAM COMMITTEE:
Kenneth Arrow
Department of Economics
Stanford University
Stanford, California
Jerome Feldman
International Computer Science Institute
147 Center Street
Berkeley, California
Richard Karp
Computer Science Department
University of California at Berkeley
Berkeley, California
Christos Papadimitriou
Computer Science Department
University of California at San Diego
San Diego, California
Steven Smale
Mathematics Department
University of California at Berkeley
Berkeley, California
Joseph Traub
Computer Science Department
Columbia University
New York, New York
Henryk Wozniakowski
Computer Science Department
Columbia University
New York, New York
Donald Ylvisaker
Statistics Department
University of California at Los Angeles
Los Angeles, California
PARTIAL LIST OF SPEAKERS
PLENARY SPEAKERS:
Leon N. Cooper
Brown University
Steven Smale
University of California, Berkeley
INVITED SPEAKERS:
Yaser Abu-Mostafa
California Institute of Technology
Lenore Blum
International Computer Science Institute, Berkeley
Adam Bojanczyk
Cornell University
Terrance Boult
Columbia University
David Donoho
University of California, Berkeley
Zvi Galil
Columbia University
Feng Gao
University of British Columbia
Stefan Heinrich
Akademie der Wissenschaften der DDR
Ehud Kalai
Northwestern University
Mark Kon
Boston University
Marek A. Kowalski
University of Warsaw
J. Kuczynski
University of Warsaw
David Lee
AT&T Bell Laboratories
Leonid Levin
Boston University
Mario Milanese
Politecnico di Torino
Erich Novak
University of Erlangen
James Renegar
Cornell University
Donald Saari
Northwestern University
Michael Shub
IBM, T.J. Watson Research Center
K. Sikorski
University of Utah
Michael Steele
Princeton University
Aleksei Sukhare
Moscow State University
Prasoon Tiwari
IBM, T.J. Watson Research Center
John N. Tsitsiklis
Massachusetts Institute of Technology
Umesh Vazirani
University of California, Berkeley
Grace Wahba
University of Wisconsin
Greg Wasilkowski
University of Kentucky
Arthur Werschulz
Columbia University
Henryk Wozniakowski
Columbia University
Yosef Yomdin
Institute for Advanced Study, Princeton
SOME OF THE TOPICS TO BE ADDRESSED ARE:
Average Case Analysis of Algorithms Neural Nets
Computational Complexity Optimal Recovery
Computer Vision Parallel Computation
Connectionist Models Prediction and Estimation
Continuous Complexity Random Algorithms
Decision Theory Random Complexity
Design of Experiment Robotics
Distributed Complexity Scientific Computation
Information-Based Complexity Seismology
Inverse Problems Signal Processing
Mathematical Economics
CONTRIBUTED PAPERS: All appropriate papers for which abstracts are
contributed will be scheduled. Contributed papers will be twenty
minutes in length.
To contribute a paper send title, author, affiliation, and abstract on
a single 8 1/2 by 11 sheet of paper or by electronic mail.
The above can be sent by U.S. mail to:
J.F. Traub
Computer Science Department
Columbia University
450 Computer Science Building
New York, New York 10027
Electronic Mail: kerny@cs.columbia.edu
TITLES AND ABSTRACTS MUST BE RECEIVED BY NO LATER THAN FEBRUARY 1, 1989
PUBLICATION: Invited papers will be published in the Journal of Complexity.
REGISTRATION: The symposium will be held in the Kellogg Conference
Center, on the fifteenth floor of the International Affairs Building,
Columbia University, 118th Street and Amsterdam Avenue. Registration
will start at 9:00 a.m. THERE IS NO REGISTRATION CHARGE.
FOR FURTHER INFORMATION: The program schedule will be sent
electronically about March 1, 1989. If you have any questions,
contact Kerny McLaughlin, Computer Science Department, Columbia
University, (212) 854-2736.
To help us plan the symposium please complete the information
below and return by U.S. Mail to Traub or by electronic mail to
kerny@cs.columbia.edu.
-------------------------------------------
SYMPOSIUM ON COMPLEXITY OF APPROXIMATELY SOLVED PROBLEMS
April 3-5, 1989
Name:
Affiliation:
Address:
[ ] I will attend the Complexity Symposium.
[ ] I may attend the Complexity Symposium.
[ ] I will contribute a paper.
∂19-Jan-89 2324 hoffman@csli.Stanford.EDU Symbolic Systems Forum Reminder
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Jan 89 23:24:37 PST
Received: by csli.Stanford.EDU (4.0/inc-1.0)
id AA06774; Thu, 19 Jan 89 23:16:57 PST
Date: Thu 19 Jan 89 23:16:56-PST
From: Reid Hoffman <HOFFMAN@CSLI.Stanford.EDU>
Subject: Symbolic Systems Forum Reminder
To: TheForum@csli.Stanford.EDU
Message-Id: <601283816.0.HOFFMAN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
The Symbolic Systems Forum -- Jan. 20th -- will host
Professor Stan Rosenschein (CS and Teleos Research, Inc.),
speaking on
What Artificial Intelligence is;
What Artificial Intelligence is not.
Time: 3:15
Room: 60-61j
Building: 60 (to the right of Memorial Church as you walk
in from the Oval)
Chocolate Chip Cookies and Refreshments provided.
(CSLI Internships will also announced.)
-------
∂20-Jan-89 0852 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Faculty Lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Jan 89 08:52:27 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 20 Jan 89 08:48:27-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA18532; Fri, 20 Jan 89 08:49:27 PDT
Date: Fri, 20 Jan 1989 8:49:25 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, bureaucrats@score, phd-prcom@score
Subject: Faculty Lunch
Message-Id: <CMM.0.87.601318165.chandler@polya.stanford.edu>
The next faculty lunch will be held in MJH-146 next Tuesday, 1/24. Ed
Feigenbaum, Bob Floyd and Mike Genesereth will talk about how the Stanford CS
Department ought to train PhD students. THIS MEETING WILL BEGIN PROMPTLY AT
12:10.......Yes, that's 12:10, not 12:15ish.
See you there!
∂20-Jan-89 1049 @Score.Stanford.EDU:chandler@polya.Stanford.EDU CSD Retreat
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Jan 89 10:49:10 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 20 Jan 89 10:41:34-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA23664; Fri, 20 Jan 89 10:42:32 PDT
Date: Fri, 20 Jan 1989 10:42:11 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, brown@sumex-aim, engelmore@sumex-aim, ok@sail, val@sail,
nii@sumex-aim, ponce@coyote, rindfleisch@sumex-aim
Cc: chandler@polya.Stanford.EDU
Subject: CSD Retreat
Message-Id: <CMM.0.87.601324932.chandler@polya.stanford.edu>
We're looking at the weekend of 5/5-7 to have the annual CSD retreat. In
order to begin making plans I will need to know your interest in attending.
Are you:
1. Definitely planning to attend?
2. Maybe planning to attend?
3. Definitely not planning to attend?
∂20-Jan-89 1230 LOGMTC-mailer seminar in logic
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Jan 89 12:30:28 PST
Received: by csli.Stanford.EDU (4.0/inc-1.0)
id AA19341; Fri, 20 Jan 89 12:28:47 PST
Date: Fri 20 Jan 89 12:28:46-PST
From: Sol Feferman <SF@CSLI.Stanford.EDU>
Subject: seminar in logic
To: logic@csli.Stanford.EDU
Message-Id: <601331326.0.SF@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
Seminar in Logic and Foundations
Speaker: Prof. Philip Scowcroft, Mathematics, Stanford
Title: "Introduction to Intuitionistic Mathematics" (first of two lectures)
Time: Tues. Jan 24, 4:15-5:30 PM
Place: Room 381-T, Math Corner Stanford
S. Feferman
-------
∂20-Jan-89 1532 @Score.Stanford.EDU:latombe@coyote.stanford.edu Re: CSD Retreat
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Jan 89 15:32:32 PST
Received: from coyote.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 20 Jan 89 15:28:00-PST
Received: by coyote.stanford.edu; Fri, 20 Jan 89 14:52:29 PST
Date: Fri, 20 Jan 89 14:52:29 PST
From: Jean-Claude Latombe <latombe@coyote.stanford.edu>
Subject: Re: CSD Retreat
To: brown@sumex-aim.Stanford.EDU, chandler@polya.stanford.edu,
engelmore@sumex-aim.Stanford.EDU, faculty@score.Stanford.EDU,
nii@sumex-aim.Stanford.EDU, ok@sail.Stanford.EDU,
ponce@coyote.Stanford.EDU, rindfleisch@sumex-aim.Stanford.EDU,
val@sail.Stanford.EDU
I am in case 2
JCL
∂20-Jan-89 1630 @polya.Stanford.EDU:decwrl!decvax!gatech!cs.utexas.edu!utep-vaxa!teodor@labrea.stanford.edu mailing list
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Jan 89 16:27:02 PST
Received: from labrea.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA12021; Fri, 20 Jan 89 16:24:04 PDT
Received: from decwrl.dec.com by labrea.stanford.edu with TCP; Fri, 20 Jan 89 16:22:50 PST
Received: from decvax.dec.com by decwrl.dec.com (5.54.5/4.7.34)
for labrea!polya.stanford.edu!nail; id AA01891; Fri, 20 Jan 89 16:22:52 PST
Received: from cs.utexas.edu.UUCP with UUCP by gatech.edu (5.58/GATECH-8.6)
id AA09176 for ; Fri, 20 Jan 89 18:43:07 EST
Posted-Date: Fri, 20 Jan 89 13:27:52 MST
Received: by cs.utexas.edu (5.59/1.23)
id AA15012; Fri, 20 Jan 89 15:00:23 CST
Received: by utep-vaxa.UUCP (5.51/smail2.2/03-26-87)
id AA02886; Fri, 20 Jan 89 13:27:52 MST
Date: Fri, 20 Jan 89 13:27:52 MST
From: decwrl!decvax!gatech!cs.utexas.edu!utep-vaxa!teodor@labrea.stanford.edu (teodor%utep.uucp@cs.utexas.edu [Teodor C. Przymusinski])
Message-Id: <8901202027.AA02886@utep-vaxa.UUCP>
To: polya.stanford.edu!nail@cs.utexas.edu
Subject: mailing list
Please my new address to the nail mailing list:
teodor%utep.uucp@cs.utexas.edu
and delete my old address:
teodor@utep.bitnet
Thank you!
Teodor Przymusinski
∂21-Jan-89 0042 hoffman@csli.Stanford.EDU Symbolic Systems Forum Jan 27th
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Jan 89 00:42:07 PST
Received: by csli.Stanford.EDU (4.0/inc-1.0)
id AA05943; Sat, 21 Jan 89 00:35:32 PST
Date: Sat 21 Jan 89 00:35:31-PST
From: Reid Hoffman <HOFFMAN@CSLI.Stanford.EDU>
Subject: Symbolic Systems Forum Jan 27th
To: TheForum@csli.Stanford.EDU
Message-Id: <601374931.0.HOFFMAN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
The Symbolic Systems Forum, Jan. 27th
Time: 3:15PM
Place: Building 60, Room 62N (although it may also relocate to another room
in the building, in which case it will be posted.)
Professor Peter Sells (Linguistics) will speak on
Quantification in Natural Language
In this talk I'd like to look at the relation between a first-order
logic style representation for quantification and the way that
quantificational structures are manifest in natural languages, and the
way in which that interacts with other "variable"-like elements in natural
language, such as pronouns. There has been quite a lot of work in
recent years on existential quantification in natural languages, which
seems to diverge quite a lot from the picture you would expect from
standard logic, and I'll probably concentrate on that, using data from
English and Japanese.
The talk is open to the general public. To add yourself to the mailing list,
send mail to hoffman@csli.stanford.edu.
-------
∂21-Jan-89 1406 byrd@sumex-aim.stanford.edu object-oriented paper
Received: from sumex-aim.stanford.edu by SAIL.Stanford.EDU with TCP; 21 Jan 89 14:06:32 PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA12545; Sat, 21 Jan 89 14:05:42 PST
Date: Sat, 21 Jan 1989 14:05:41 PST
From: Greg Byrd <byrd@sumex-aim.stanford.edu>
To: aap@sumex-aim.stanford.edu
Subject: object-oriented paper
Message-Id: <CMM.0.88.601423541.byrd@sumex-aim.stanford.edu>
I just got a the paper, "Inheritance in Actor Based Concurrent
Object-Oriented Languages," by Kafura and Keung (Va. Tech) that
was mentioned in the net a couple of weeks ago. If anyone wants
to see it (or copy it) let me know.
...Greg
∂23-Jan-89 1016 @Score.Stanford.EDU:winograd@loire.stanford.edu PhD program discussion
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Jan 89 10:16:40 PST
Received: from loire.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 23 Jan 89 10:08:28-PST
Received: by loire.stanford.edu (5.59/25-eef) id AA26177; Mon, 23 Jan 89 10:08:22 PDT
Date: Mon, 23 Jan 89 10:08:22 PDT
Message-Id: <8901231808.AA26177@loire.stanford.edu>
From: Terry Winograd <Winograd@csli.stanford.edu>
To: faculty@score
Subject: PhD program discussion
I am giving a colloquium at UCLA tomorrow and can't be here for the
lunch discussion, so I wanted to toss in a couple of points that I
hope won't be forgotten:
1) Not all of our PhD students see their career as devoted to
research. Traditionally, the PhD is a degree for people who will teach
in universities, and even though current career economics in our
discipline militate against it, it is still important that we think
about how we are training the next generation of teachers. We might
start by asking "What aspects of our own training have contributed to
the problems we see in the educational program here?"
2) People with a narrow training in a subdiscipline may do the fastest
research, but in the long run they don't do the best research. Many
things that appear only tangentially relevant when they are learned
will turn out to give key insights at a later point. The problem is
that you can't tell ahead of time which ones they will be, so the only
way to have them available is to have some breadth and diversity in
what you learn.
3) No set of requirements is right for everyone, and no mechanical
application of rules will make it work. In some venerable traditions
of education, a faculty mentor takes on the responsibility for working with
a student to develop a full education, not just the skills necessary for
doing good work on a sponsored project. This kind of individual
concern is much more effective than any set of procedures. How do we
foster it in general? How do we make it available to all students,
not just those with a particular interest area or those who are perceived
of as being at the top of the heap?
--t
∂23-Jan-89 1048 debra@russell.Stanford.EDU REMINDER
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Jan 89 10:48:28 PST
Received: from localhost by russell.Stanford.EDU (4.0/inc-1.0)
id AA13798; Mon, 23 Jan 89 10:48:50 PST
Message-Id: <8901231848.AA13798@russell.Stanford.EDU>
To: evesem@russell.Stanford.EDU
Cc: debra@russell.Stanford.EDU, kuder@russell.Stanford.EDU
Subject: REMINDER
Date: Mon, 23 Jan 89 10:48:48 PST
From: Debra Alty <debra@russell.Stanford.EDU>
REMINDER
The next EVENING SEMINAR will be Wednesday, February 25th @ 7:30pm in
the CSLI Cordura conference Room.
Professor John McCarthy, Computer Science Department, will be leading
the discussion.
The following will be served:
Antipasto tray Cognac
meats Wine
marinated vegetables Beer
relishes Sparkling Waters
Cheese Coffee
Crackers/Bread Tea
Strawberries dipped
in chocolate
Debra
If you have any menu request and/or suggestions, please feel free to
EM me -- the menu is very flexible.
debra@csli.stanford.edu
∂23-Jan-89 1051 X3J13-mailer Issues DECLARATION-SCOPE and DEFINING-MACROS-NON-TOP-LEVEL
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Jan 89 10:51:37 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 525301; Mon 23-Jan-89 13:49:15 EST
Date: Mon, 23 Jan 89 13:49 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issues DECLARATION-SCOPE and DEFINING-MACROS-NON-TOP-LEVEL
To: sandra%defun@cs.utah.edu, X3J13@sail.stanford.edu
Message-ID: <19890123184939.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Since the X3J13 meeting last week passed DECLARATION-SCOPE:NO-HOISTING
(instead of LIMITED-HOISTING), it is no longer possible to make a declaration
that applies to an entire DEFUN, DEFMACRO, or DEFMETHOD by placing a DECLARE
at the head of the body. Such declarations have been incompatibly changed
to apply only to the body.
The problem is that (LOCALLY (DECLARE ...) (DEFUN ...)) cannot be used as
the new way to say what used to be said as (DEFUN ... (DECLARE ...) ...),
even though side-discussion at the meeting indicated that some people
thought that was a valid workaround. DEFINING-MACROS-NON-TOP-LEVEL
does not list LOCALLY as one of the forms whose body is handled at top
level. CLtL says LOCALLY is a macro, but doesn't say what it macroexpands
into. Presumably it macroexpands into a LET that doesn't bind any variables,
which DEFINING-MACROS-NON-TOP-LEVEL says (or implies) does not have a body
that is handled at top level.
Assuming the vote on DECLARATION-SCOPE is not likely to be reversed, I
think DEFINING-MACROS-NON-TOP-LEVEL needs to be modified to treat the
body of LOCALLY as top-level. If this requires changing LOCALLY from a
macro to a special form, so be it.
∂23-Jan-89 1059 debra@russell.Stanford.EDU EVENING SEMINAR REMINDER
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Jan 89 10:59:35 PST
Received: from localhost by russell.Stanford.EDU (4.0/inc-1.0)
id AA13873; Mon, 23 Jan 89 10:59:57 PST
Message-Id: <8901231859.AA13873@russell.Stanford.EDU>
To: evesem@russell.Stanford.EDU
Subject: EVENING SEMINAR REMINDER
Date: Mon, 23 Jan 89 10:59:56 PST
From: Debra Alty <debra@russell.Stanford.EDU>
The date of the next EVENING SEMINAR should have read:
JANUARY 25th, not February!
Sorry for the error.
Debra
∂23-Jan-89 1409 X3J13-mailer Second edition of "Common Lisp: The Language"
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 23 Jan 89 14:09:07 PST
Received: from fafnir.think.com by Think.COM; Mon, 23 Jan 89 16:45:35 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 23 Jan 89 17:05:55 EST
Received: by verdi.think.com; Mon, 23 Jan 89 17:04:42 EST
Date: Mon, 23 Jan 89 17:04:42 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8901232204.AA14004@verdi.think.com>
To: x3j13@sail.stanford.edu
Subject: Second edition of "Common Lisp: The Language"
The following is a paraphrase of what I announced at the last X3J13
meeting in Hawaii.
I am now working fairly full steam on a second edition of CLtL. Digital
Press would like to have it out this summer, and I think that would be the
optimal timing for it. The purpose of a second edition is to provide the
implementation and user community with feedback on what X3J13 has done so
far, in a manner that links the committee's decisions with the current
structure of CLtL. (The eventual standard will be organized in a
completely different manner.) This will provide a bridge between the first
edition of five years ago and the eventual standard (which may be another
two or more years away). In addition, I will be adding commentary of my
own about difficult places in the language, more examples, etc. For
example, I am attempting to explain nested backquotes so you can understand
them. I also promise that the second edition will have a better index.
The second edition will contain the entire contents of the first edition.
New material will be distinguished from the old, and clearly marked as to
whether it is the result of an X3J13 vote, an informal comment that came up
in X3J13 meetings, or my own commentary. The preface will contain
appropriate disclaimers, including that additional meetings and a public
review period are yet to come, that X3J13 may reverse any decision at any
time, that X3J13 does not officially endorse the second edition, that
no member of X3J13 necessarily endorses what I write, and that where new
examples conflict with old material or with X3J13 votes, the new examples
have lesser priority (I hope this doesn't occur!).
I plan to include material on cleanups and compiler cleanups so far. I
would like to include the condition system and LOOP. Dick Waters also once
spoke to me about including an appendix on OSS in order to publicize this
alternative approach to iteration; now that OSS and generators seem to be
converging, I'm not sure what would be appropriate, but am open to
suggestions.
I do *not* plan to include any material about CLOS beyond a short overview
of five to ten pages, plus a few inserts describing such general features
as PRINT-OBJECT and SYMBOL-MACROLET that impinge on the rest of the
language. I will include pointers to CLOS chapters 1 and 2 as published
in LASC and SIGPLAN Notices, and to Sonya Keene's book (I certainly
couldn't do any better than she did).
I will be relying on work done by a lot of people, and I will be asking
some of you for very specific help in the next few weeks. It seems to me
that these many people ought to benefit from the royalties generated.
I looked into various methods of compensation, but it became extremely
complicated, both procedurally and legally, and there was always th
danger of overlooking someone. I have turned instead to the notion of
donating royalties toward some worthy cause(s) that would benefit the
Lisp community at large. (This idea met with general informal approval
at the last X3J13 meeting when I announced it.) I first looked into
financing travel so that students could attend the coming Lisp and
History of Lisp (LISPHOL) Conference; SIGPLAN has a fund for that purpose.
It turns out that this fund is undersubscribed; SIGPLAN has more funds
than applications, and David Wise urged me to look for some other project.
Two more promising possibilities are underwriting some of the costs
of making good historical records at LISPHOL, and donating funds to
The Computer Museum to establish a collection and perhaps exhibits
on the History of Lisp. I would be glad to receive other suggestions
for appropriate projects.
I hope to have a complete draft ready within several weeks. I will be
sending a copy of this draft to every member of X3J13. To be useful,
feedback would be needed within a few weeks. (Note that the new material
will be distinguished by some typographical device such as lines in the
margins, so you shouldn't have to read an entire 500-page draft!) I will
also send a copy of the finished, published book to every member of X3J13
once it is available, as well as to certain other persons who have made
contributions.
--Guy
∂23-Jan-89 1423 X3J13-mailer cl-compiler issues
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Jan 89 14:23:03 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
id AA11470; Mon, 23 Jan 89 15:21:37 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
id AA19082; Mon, 23 Jan 89 15:21:33 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901232221.AA19082@defun.utah.edu>
Date: Mon, 23 Jan 89 15:21:32 MST
Subject: cl-compiler issues
To: x3j13@sail.stanford.edu
At the Hawaii meeting, the following cl-compiler issues were passed:
ALLOW-LOCAL-INLINE
DEFCONSTANT-SPECIAL (amended)
LOAD-TIME-EVAL (amended)
SHARP-COMMA-CONFUSION
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS (amended)
CONSTANT-MODIFICATION
Copies of these proposals (incorporating the amendments) are available
for anonymous FTP from cs.utah.edu (that's 128.110.4.21), in directory
cl-compiler/passed. There are also copies of the proposals that were
passed at the October meeting in this directory.
Also, I want to remind you all that we are still soliciting comments
on the remaining issues that were distributed earlier this month. In
particular, issue COMPILE-ENVIRONMENT-CONSISTENCY was tabled because
some people at the meeting indicated they wanted to see some changes
to the writeup, and I need to know what those changes are.
E-mail on compiler issues should be sent to cl-compiler@sail.stanford.edu.
We appreciate it if you send a separate message for each issue, and
include the issue name in the message subject line.
-Sandra
-------
∂23-Jan-89 1459 @Score.Stanford.EDU:jle@Orange.stanford.edu CS Colloquia
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Jan 89 14:59:18 PST
Received: from Orange.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 23 Jan 89 14:53:28-PST
Received: by Orange.stanford.edu (5.59/25-eef) id AA03057; Mon, 23 Jan 89 14:53:49 PDT
Date: Mon, 23 Jan 89 14:53:49 PDT
From: Jeffrey Eppinger <jle@Orange.stanford.edu>
Message-Id: <8901232253.AA03057@Orange.stanford.edu>
To: faculty@score
Subject: CS Colloquia
Due to scheduling problems, there will be no CS Colloquium on January 31, 1989.
The next CS Colloquium will be on February 14th. (This colloquium is also the
second of this year's Forsythe Lectures.)
Computer Science Colloquium
Tuesday, February 14, 1989, 4:15pm
Jordan Hall (Building 420), Room 040
Stanford University
Perception via Active Exploration
Examples of Disassembly
Ruzena Bajcsy
Computer and Information Science Department
University of Pennsylvania
Philadelphia, PA 19104-6389
Abstract
It has been accepted by most psychologists (e.g., Gibson) that perception
is an active process, that is, an interaction of the perceptual system with
its environment. In this presentation we shall limit the perceptual system
to only two modalities: the Visual and the Haptic. The goal of our work is
to answer *what are the primitive actions and attributes* that are measurable
and or computable from Visual and Haptic modality that are necessary for
dissassembly of a scene or a two part-object. While a great deal of attention
has been paid to visual information processing both in psychological and
machine perception literature, haptic processing always took the second seat.
Haptic information processing is the identification of objects by touch (the
use of kinesthetic and tactile information). We shall develop a theory and
present two experiments to show an existential proof of our theory. Another
obvious observation is that vision is limited, especially in discerning two
separate objects when touching from the case of part-whole relationship of
one object. Take an example of a cup on a saucer. From vision alone one
cannot establish whether the saucer is glued to the cup or the cup is just
sitting on the saucer. The only way to disambiguate this situation is to
pick up the cup or shake it, in other words to perform some manipulation
operation.
The goal of this research is perception (apprehension) via exploration.
This means to us data driven perception which results in discerning solid
separable objects and describing them in terms of their structural and
geometric properties. Our aim is to explore complex scenes composed of more
than one object in arbitrary positions. Our basic hypothesis is that this
cannot be done by vision alone, that one needs some possibilities of
manipulation and the use of haptic information processing. Much of our
stimulation, especially in the area of haptic information processing, comes
from the studies and discussions of Klatzky and Lederman.
∂23-Jan-89 1503 misha@polya.Stanford.EDU TWO AFLB talks this week!
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Jan 89 15:03:39 PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA12735; Mon, 23 Jan 89 15:00:37 PDT
Date: Mon, 23 Jan 89 15:00:37 PDT
From: Michael Kharitonov <misha@polya.Stanford.EDU>
Message-Id: <8901232300.AA12735@polya.Stanford.EDU>
To: aflb-all@polya.Stanford.EDU
Subject: TWO AFLB talks this week!
David Shmoys from MIT will give a talk TOMORROW, Jan 24, at 4:15
in room 301. The talk will be:
Approximation Algorithms for
Constrained Parallel Machine Scheduling Problems
In this talk, we consider the effect of precedence constraints
on the complexity of scheduling problems.
In particular, we shall consider the following scheduling problem:
there are n independent jobs to be scheduled on m identical parallel
machines; each job may scheduled only after a specified release
date; each job has a due date, and the objective is minimize
the maximum lateness. If, in addition, there are precedence
constraints, we show that a simple heuristic delivers
solutions that are no worse than twice optimal, and by
a result of Lenstra & Rinnooy Kan, no algorithm exists that guarantees
better than a factor of 4/3 unless P=NP. Without precedence constraints,
we present a polynomial approximation scheme. For scheduling problems
with precedence constraints, it is typical that no algorithms are known
that guarantee better than a factor of 2, but in the special case where
m=1, the first result can be improved to a factor of 4/3.
--------------------------------------------------------
Eva Tardos from MIT will speak at the regular AFLB meeting on Thursday
at 12:30 in room 352. The title of her talk is:
Combinatorial algorithhms for the generalized
network flow problem
(joint work with Andrew Goldberg and Serge Plotkin)
∂23-Jan-89 1518 saraiya@sumex-aim.stanford.edu [Nevena Raykovic <nevena@pescadero.stanford.edu> : CS548-Distributed
Received: from sumex-aim.stanford.edu by SAIL.Stanford.EDU with TCP; 23 Jan 89 15:18:39 PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA05884; Mon, 23 Jan 89 15:17:13 PST
Date: Mon, 23 Jan 1989 15:17:13 PST
From: Nakul P. Saraiya <saraiya@sumex-aim.stanford.edu>
To: aap@sumex-aim.stanford.edu
Subject: [Nevena Raykovic <nevena@pescadero.stanford.edu> : CS548-Distributed
Systems Seminar ]
Message-Id: <CMM.0.88.601600633.saraiya@sumex-aim.stanford.edu>
From: Nevena Raykovic <nevena@pescadero.stanford.edu>
To: colloq@score.stanford.edu
Cc: dsgworld@pescadero.stanford.edu
Subject: CS548-Distributed Systems Seminar
The seminar will be held on Thursday, Jan. 26 at 4:15 in Margaret Jacks
Hall - room 352.
Synchronization in Parallel Programs
Helen Davis
Delays at synchronization points can substantially increase the run
time of a parallel program. This makes it important to characterize
the synchronization behavior of programs and to provide analysis tools
to aid both the hardware and software designer in evaluating design
alternatives. This talk will describe a tracing facility that permits
fast tracing of the synchronization (and shared memory reference) behavior
of parallel programs.
We have used this facility to study several applications running on
a moderate number of processors. Several program characteristics that can
limit speedup were uncovered and will be discussed. Extensions that allow
us to trace the behavior of programs that use more processors than are
currently available will also be discussed.
∂23-Jan-89 1722 TAJNAI@Score.Stanford.EDU "taxes on gifts"
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Jan 89 17:22:52 PST
Date: Mon 23 Jan 89 17:18:42-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: "taxes on gifts"
To: faculty@Score.Stanford.EDU, srstaff@Score.Stanford.EDU
cc: hiller@Score.Stanford.EDU
Message-ID: <12464961527.14.TAJNAI@Score.Stanford.EDU>
The following memo was received from Prof. Levinthal. Please send your
comments to me.
17-Jan-89 14:41:15-PST,4121;000000000001
Return-Path: <leboeuf@sierra.STANFORD.EDU>
Received: from sierra.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Tue 17 Jan 89 14:41:11-PST
Received: by sierra.STANFORD.EDU (3.2/4.7); Tue, 17 Jan 89 14:39:19 PST
From: leboeuf@sierra.STANFORD.EDU (Kelly O. LeBoeuf)
Date: Tue, 17 Jan 1989 14:39:18 PST
To: ashley@sierra.STANFORD.EDU, hughes@sierra.STANFORD.EDU,
crsteele@sierra.STANFORD.EDU, lbbauman@sierra.STANFORD.EDU,
tajnai@sierra.STANFORD.EDU, fondahl@sierra.STANFORD.EDU,
barkan@sierra.STANFORD.EDU, design@sierra.STANFORD.EDU,
leifer@sierra.STANFORD.EDU, krawinkler@sierra.STANFORD.EDU,
kiremidjian@sierra.STANFORD.EDU, lb.jls@forsythe,
hausman@sierra.STANFORD.EDU, hellman@isl, tiller@sierra.STANFORD.EDU,
ca.foh@forsythe, pease@sierra.STANFORD.EDU, inan@sierra.STANFORD.EDU,
journel@sierra.STANFORD.EDU, jpj@sierra.STANFORD.EDU,
hghuntington@sierra.STANFORD.EDU
Cc: levinthal@sierra.STANFORD.EDU
Subject: Affiliate Programs
SCHOOL OF ENGINEERING
MEMORANDUM
JANUARY 17, 1989
To: Distribution
From: Elliott Levinthal
Associate Dean for Research
Subject: AFFILIATE PROGRAMS
There has been considerable discussion at various levels in the
University about what has been come to be called "taxes on gifts".
The fundamental question is whether or not some of the indirect
costs that are generated by the expenditure of gifts should be
recovered. Included in the question are gifts to individuals,
Affiliates programs and Centers. In order to be able to properly
deal with this issue as it might impact Affiliate programs, it is
urgent that we have we have more information. Dean Gibbons and
I are meeting with Robert Byer, Vice- Provost for Research, January
30, 1989 and we would like to be as well informed as possible at
that time. Please respond no later than Friday, January 27th. I
realize that this doesn't give you much time. However, we do not
need precise numbers at this time.
The questions, for which I need answers, relate to the income of the
Affiliate programs and the allocation of that income.
I. Income:
a. What is the total annual income for your Affiliate program?
Give last years and the current year. Estimate the current year, if
the total is not known.
b. How many members did you have last year and do you have
in the current year?
c. What is the annual fee.
II. Allocations:
What fraction of the income is spent in the following
categories?
a. General academic support of the Department or Division in
which the Affiliate program resides.
b. Support of educational goals such as curricula development or
scheduled courses.
c. Administration of the Affiliate program itself, including
travel to maintain the program, etc.
d. Research support of the Affiliated faculty as a whole and
under the budgetary control of the group as a whole.
e. Allocated to an individual faculty discretionary fund
account.
Are there other categories that more accurately describe the
allocation of your funds?
Please give me any other information that you feel will be
useful in considering this issue.
MEETING NOTICE....MEETING NOTICE......:
We will be having a meeting of the School of Engineering
Research Advisory committee on January 27, 1989 at 3 pm in
Durand Room 450, This issue will be the sole topic on the agenda.
Please feel free to attend that meeting.
DISTRIBUTION:
Holt Ashley Thomas Hughes
Charles Steele Michel Boudart
Lindi Bauman Carolyn Tajnai
John Fondahl Philip Barkan
Lori Magee Larry Leifer
Helmut Krawinkler Anne Kiremidjian
James Sweeney Warren Hausman
Martin Hellman William Tiller
Frederick Hillier Fabian Pease
Umran Inan Andre Journel
James Johnston Hillard Huntington
-------
∂24-Jan-89 0852 @Score.Stanford.EDU:gio@sumex-aim.stanford.edu Re: "taxes on gifts"
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Jan 89 08:51:55 PST
Received: from sumex-aim.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 24 Jan 89 08:48:42-PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA21391; Tue, 24 Jan 89 08:50:02 PST
Date: Tue, 24 Jan 1989 8:50:02 PST
From: Gio Wiederhold <gio@sumex-aim.stanford.edu>
To: Carolyn Tajnai <TAJNAI@score.stanford.edu>
Cc: faculty@score.stanford.edu, srstaff@score.stanford.edu,
hiller@score.stanford.edu, faculty@score.stanford.edu
Subject: Re: "taxes on gifts"
In-Reply-To: Your message of Mon 23 Jan 89 17:18:42-PST
Message-Id: <CMM.0.88.601663802.gio@sumex-aim.stanford.edu>
I am afraid I agree with a modest tax on gift income, to offset the excessive
sponsored grants burden. What will the controls be? Gio
∂24-Jan-89 0905 TAJNAI@Score.Stanford.EDU Re: "taxes on gifts"
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Jan 89 09:05:01 PST
Date: Tue 24 Jan 89 09:00:34-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Re: "taxes on gifts"
To: gio@SUMEX-AIM.Stanford.EDU
cc: faculty@Score.Stanford.EDU, srstaff@Score.Stanford.EDU,
hiller@Score.Stanford.EDU, faculty@Score.Stanford.EDU
In-Reply-To: <CMM.0.88.601663802.gio@sumex-aim.stanford.edu>
Message-ID: <12465132989.22.TAJNAI@Score.Stanford.EDU>
The only figure I have heard is that they are considering 10% tax when the
money is spent. This information came from Stanley Peters.
Carolyn
-------
∂24-Jan-89 0942 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu POSITION ANNOUNCEMENT
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Jan 89 09:42:51 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA18547; Tue, 24 Jan 89 09:42:18 PDT
Message-Id: <8901241742.AA18547@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 24 Jan 89 09:41:01 PST
Received: by BYUADMIN (Mailer R2.01A) id 3062; Tue, 24 Jan 89 10:40:16 MST
Date: Tue, 24 Jan 89 10:25:59 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
DJMCGUINNESS%GALLUA.BITNET@forsythe.stanford.edu
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: DJMCGUINNESS%GALLUA.BITNET@forsythe.stanford.edu
Subject: POSITION ANNOUNCEMENT
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
GALLAUDET UNIVERSITY
Department of Mathematics
and Computer Science
Applications are invited for a tenure-track position in Computer
Science at the Instructor or Assistant Professor level, available
August 1989. Applicants are expected to have a commitment to
excellence in teaching and must have a Master's in Computer Science
with experience or course work in, but not limited to, such subjects
as: Software Engineering, Artifical Intelligence, Computer Graphics,
Discrete Mathematics, Database and Knowledge Systems or Computer Networks.
Gallaudet University, a small institution offering undergraduate
programs for deaf students and graduate programs for both hearing
and deaf, is located in Washington, D.C. Hearing impaired individuals
are encouraged to apply for the position. Appointees without sign
language skills will be required to attend an 8-week paid sign
language training program in June, 1989.
Closing date for application is March 1989, or until the position is
filled. Send vita, transcripts, and three letters of reference to:
Prof. Herbert G. Mapes, Chair, Department of Mathematics and Computer
Science, Gallaudet University, Washington, D.C. 20002.
Gallaudet University is an EEO/AA employer.
∂24-Jan-89 0944 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Theory Day - last announcement
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Jan 89 09:44:22 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA18604; Tue, 24 Jan 89 09:43:38 PDT
Message-Id: <8901241743.AA18604@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 24 Jan 89 09:42:39 PST
Received: by BYUADMIN (Mailer R2.01A) id 3131; Tue, 24 Jan 89 10:41:17 MST
Date: Tue, 24 Jan 89 10:28:34 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
andrew klapper <klapper@CORWIN.CCS.NORTHEASTERN.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: andrew klapper <klapper@CORWIN.CCS.NORTHEASTERN.EDU>
Subject: Theory Day - last announcement
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
-------------------------------------------------------------------------------
The College of Computer Science at Northeastern University
announces its 1989
THEORY DAY
Friday, January 27, 1989
.......................... Schedule of Events ................................
10:00 AM Eric Allender "Limitations of the Upward Separation Technique"
11:00 AM Joan Feigenbaum "Generating Hard Certified Elements of
NP-Complete Sets"
12:00 PM Lunch Break
2:00 PM Gilles Brassard "Minimum Disclosure Proofs of Knowledge"
3:30 PM Ken MacAloon "Constraint Logic Programming"
All talks will take place in room 356 Ell Center on the Northeastern University
campus. Parking on campus will be available but requires prior approval. For
information about visitor parking and maps of campus or for any other
information, please contact Gayle Mackay:
College of Computer Science
Northeastern University
360 Huntington Ave.
Boston, MA 02115
(617) 437-2464
or contact Andy Klapper at klapper@corwin.ccs.northeastern.edu
∂24-Jan-89 1133 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu STOC '89: TENTATIVE PROGRAM
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Jan 89 11:32:50 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA25640; Tue, 24 Jan 89 11:32:06 PDT
Message-Id: <8901241932.AA25640@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 24 Jan 89 11:31:07 PST
Received: by BYUADMIN (Mailer R2.01A) id 5190; Tue, 24 Jan 89 12:28:27 MST
Date: Tue, 24 Jan 89 10:57:55 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Christos Papadimitriou <christos%cs@ucsd.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Christos Papadimitriou <christos%cs@ucsd.edu>
Subject: STOC '89: TENTATIVE PROGRAM
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
STOC '89: TENTATIVE PROGRAM
SESSION 1
"Multiparty protocols and logspace-hard pseudorandom sequences," by
Laszlo Babai, Noam Nisan, and Mario Szegedy.
"Pseudo-random Number Generation from ANY One-way Function," by
Russell Impagliazzo, Leonid Levin, and Michael Luby.
"A Hard-Core Predicate for All One-Way Functions," by
Oded Goldreich and Leonid A. Levin.
"Universal One-Way Hash Functions and their Cryptographic Applications,"
by Moni Naor and Moti Yung.
"Limits on the Provable Consequences of One-way Permutations," by
Russell Impagliazzo and Steven Rudich.
SESSION 2
"A Zero-One Law for Boolean Privacy," by Benny Chor and Eyal Kushilevitz.
"Verifiable Secret Sharing and Multiparty Protocols with Honest Majority,"
by Tal Rabin and Michael Ben-Or.
"Designing Programs that Check Their Work," Manuel Blum and Sampath Kannan.
"Provably Fast Integer Factoring with Quasi-uniform Small Quadratic Residues,"
by Brigette Vallee.
SESSION 3
"Implicit O(1) Probe Search," by Amos Fiat and Moni Naor.
"The Cell Probe Complexity of Dynamic Data Structures,"
Michael Fredman and Michael Saks.
"On Aspects of Universality and Performance for Closed Hashing," by
Jeanette P. Schmidt and Alan Siegel.
"Verifying Partial Orders," by Claire Kenyon-Mathieu and Valerie King.
SESSION 4
"A Random Polynomial Time Algorithm for Approximating the
Volume of Convex Bodies," by Martin Dyer, Alan Frieze and Ravi Kannan
"Lines in Space --Combinatorics, Algorithms and Applications"
Bernard Chazelle, Herbert Edelsbrunner, Leonidas Guibas, and
Micha Sharir.
"Polling: A New Randomized Sampling Technique for Computational
Geometry" John H. Reif and Sandeep Sen.
"Coordinate Representation of Order Types Requires Exponential
Storage," by Jacob E. Goodman, Richard Pollack, and Bernd Sturmfels.
SESSION 5
"Work-Preserving SimulaHAR BACKtions of Fixed-Connection Networks," by Richard
Koch, Tom Leighton, Bruce Maggs, Satish Rao, and Arnold Rosenberg.
"An O(log N) Deterministic Packet Routing Scheme," by Eli Upfal.
"Fast Computation Using Faulty Hypercubes," by Johan Hastad, Tom Leighton,
and Mark Newman.
"Optimal Size Integer Division Circuits," John H. Reif and Stephen R. Tate.
"On the Complexity of Radio Communication," Noga Alon, Amotz Bar-Noy,
Nathan Linial, and David Peleg.
SESSION 6
"Local Reorientation, Global Order, and Planar Topology," by
Ming-Yang Kao and Gregory E. Shannon.
"Parallel Depth-First Search in General Directed Graphs," by
Alok Aggarwal, Richard J. Anderson, and Ming-Yang Kao.
"Highly Parallelizable Problems," by Omer Berkman, Dany Breslauer,
Zvi Galil, Baruch Schieber, and Uzi Vishkin.
"Optimal Separations Between Concurrent-write Parallel
Machines," by Ravi B. Boppana.
"CREW PRAMS and Decision Trees," by Noam Nisan.
SESSION 7
"Functional Interpretations of Feasibly Constructive Arithmetic," by
Stephen Cook and Alasdair Urquhart.
"Expressiveness of Restricted Recursive Queries," by Foto Afrati
and Stavros S. Cosmadakis.
"On w-Automata and Temporal Logic," by Shmuel Safra and Moshe Y. Vardi.
"Quantifier Elimination in the Theory of Algebraically-Closed Fields, by
Doug Ierardi.
"Probabilistic Computation and Linear Time," by Lance Fortnow and
Michael Sipser.
"The Isomorphism Conjecture Fails Relative to a Random Oracle," by
Stuart A. Kurtz, Stephen R. Mahaney and James S. Royer.
SESSION 8
"On the Method of Approximations," by A. A. Razborov.
"On the Extended Direct Sum Conjecture," by Nader H. Bshouty.
"Circuits and Local Computation"Andrew Chi-Chih Yao.
"A General Sequential Time-Space Tradeoff for Finding Unique
Elements," by Paul Beame.
"Towards a Theory of Average Case Complexity,," by
Shai Ben-David, Benny Chor, Oded Goldreich, and Michael Luby.
"Tradeoffs Between Communication and Space," by
Tak Lam, Prasoon Tiwari and Martin Tompa.
SESSION 9
"Inference of Finite Automata Using Homing Sequences," by
Ronald L. Rivest and Robert E. Schapire.
"The Minimum Consistent DFA Problem Cannot Be Approximated
within any Polynomial," by Leonard Pitt and Manfred K. Warmuth.
"Cryptographic Limitations on Learning Boolean Formulae and
Finite Automata," by Michael Kearns and Leslie G. Valiant.
"Proof of a Conjecture of R. Kannan," by Jean-Camille Birget.
SESSION 10
"Bounded Concurrent Time-Stamp Systems Are Constructible!" by Danny
Dolev and Nir Shavit.
"On the Improbability of Reaching Byzantine Agreements,"
by Ronald L. Graham and Andrew C. Yao.
"Compact Distributed Data Structures for Adaptive Routing,"
by Baruch Awerbuch, Amotz Bar-Noy, Nathan Linial, and David Peleg.
"Reliable Communication Using Unreliable Channels,"
by Hagit Attiya, Michael J. Fischer, Da-Wei Wang, and Lenore D. Zuck.
"Randomized Distributed Shortest Paths Algorithms," by Baruch Awerbuch.
SESSION 11
"On Search, Decision and the Efficiency of Polynomial-Time Algorithms,"
by Michael R. Fellows and Michael A. Langston.
"A New Fixed Point Approach for Stable Networks and Stable Marriages,"
by Tomas Feder .
"Strongly Polynomial-Time and NC Algorithms for Detecting Cycles in
Dynamic Graphs" Edith Cohen and Nimrod Megiddo.
"An O(n~0.4)-Approximation Algorithm for 3-Coloring," by Avrim Blum.
SESSION 12
"Trading Space for Time in Undirected s-t Connectivity,"
by Andrei Z. Broder, Anna R. Karlin, Prabhakar Raghavan, and Eli Upfal.
"Expanding Graphs and the Average-case Analysis of Algorithms
for Matchings and Related Problems," by Rajeev Motwani.
"New Lower Bounds on the Length of Universal Traversal Sequences,"
by Allan Borodin, Walter L. Ruzzo and Martin Tompa.
"The Electrical Resistance of a Graph, and its Applications to
Random Walks," by Ashok K. Chandra, Prabhakar Raghavan, Walter L. Ruzzo,
Roman Smolensky, and Prasoon Tiwari.
"On the Second Eigenvalue of Random Regular Graphs,"
by Joel Friedman, Jeff Kahn and Endre Szemeredi.
∂24-Jan-89 1231 CL-Characters-mailer Comments on the Character proposal dated January 1, 1989
Received: from ALDERAAN.SCRC.Symbolics.COM ([128.81.41.109]) by SAIL.Stanford.EDU with TCP; 24 Jan 89 12:31:27 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 263137; Tue 24-Jan-89 14:46:01 EST
Date: Tue, 24 Jan 89 14:46 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Comments on the Character proposal dated January 1, 1989
To: Thom Linden <Baggins@IBM.COM>
cc: CL-Characters@SAIL.STANFORD.EDU, X3J13@SAIL.STANFORD.EDU, Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM,
KMP@STONY-BROOK.SCRC.Symbolics.COM, Palter@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <19890124194625.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Please acknowledge receipt of this mail so I can be sure it was
not lost in the network. The reply needn't be CC'ed to any of
the other recipients.
Page 6 -- *all-registry-names* should be renamed to
*all-character-registry-names*; the word "registry" by itself
is too general.
Page 9 -- the fourth bullet requires a defined total ordering of all
characters. This seems unnecessary, and is impossible to implement in any
system (such as Symbolics Genera) that allows dynamic addition of character
registries by third-party software vendors and by users; in such a system
character codes have to be allocated dynamically and therefore their order
cannot be fixed ahead of time.
Page 9 -- This says an implementation must define the result of
standard-char-p on the characters it supports. I think that is incorrect.
Common Lisp fully defines the result of standard-char-p, which is NIL
for all characters added by an implementation.
Page 14 -- This EXTERNAL-WIDTH function probably should be part of a
database facility or a terminal screen template facility; I'm not sure it
is useful by itself. Also note that its result is only meaningful with
respect to a specific state of the stream. To give two examples, with the
SO/SI encoding the answer can vary by 1 depending on whether the stream is
already shifted into the correct state for the first character; with the
universal encoding Symbolics uses, the answer can vary by a lot depending on
whether the character repertoires appearing in the string have been used
earlier on the same stream (and hence have been assigned encoding numbers).
Because of this dependence on the state of the stream, I cannot think of
any correct use of EXTERNAL-WIDTH that does not involve immediately
outputting the string to the stream. Therefore I believe the same effect
can be achieved without adding any new functions, by calling FILE-POSITION,
outputting to the stream, calling FILE-POSITION again, and subtracting. If
you still want to propose this feature, you should change the name: use
"length" instead of "width", since that's the word Common Lisp always uses,
and use a name that relates to the :EXTERNAL-CODE-FORMAT option to OPEN;
for example, STRING-LENGTH-IN-EXTERNAL-CODE-FORMAT or
EXTERNAL-CODED-STRING-LENGTH.
Page 24 -- I can't figure out what you intend the meaning of SIMPLE-STRING
to be. Your report mostly does not mention it, but it doesn't say to
remove it either. If I have correctly correlated page 24 back to CLtL, you
are defining SIMPLE-STRING to be synonymous with SIMPLE-GENERAL-STRING.
Maybe what you really meant, though, was what you said in November you
would do, which was to make SIMPLE-STRING mean (AND STRING SIMPLE-ARRAY),
in other words a union of several subtypes. This is particular confusing
because Common Lisp uses the name SIMPLE-VECTOR to mean what you might call
a simple general vector, that is, (SIMPLE-ARRAY T 1) rather than
(SIMPLE-ARRAY * 1). Here are my suggestions for what to do with the
various names for string subtypes:
STRING As a union of all strings, this is fine.
GENERAL-STRING I think (VECTOR CHARACTER) is just as good.
BASE-STRING I think (VECTOR BASE-CHARACTER) is just as good.
SIMPLE-STRING Should mean (SIMPLE-ARRAY CHARACTER 1).
SIMPLE-BASE-STRING This is fine.
SIMPLE-GENERAL-STRING This name is horrible, use SIMPLE-STRING.
My rationale for these suggestions largely comes from thinking about
which of these names would ever be used in type declarations and about
how these names relate to the other names already in Common Lisp. To
repeat older comments:
Pages 19 and 20 introduce a new type named simple-base-string, in addition
to simple-string. If you think about how simple-string would be used for
compiler optimization, it makes sense for simple-string to be the name for
the single simplest representation, rather than a name for a whole family
of representations that would have to be discriminated at run time. Thus
what you call simple-base-string should be called simple-string, and what
you call simple-string should just be called (simple-array character (*)).
This would not be an incompatible change in the meaning of simple-string.
Simple-string would be analogous to simple-vector.
I changed my mind slightly on that and now claim that while SIMPLE-STRING
should still be a single representation, not a union, it should be the
representation that can hold all characters. This is both because of the
principle that correct programs should be easier to write than
extra-efficient programs, and because of the powerful analogy with the name
SIMPLE-VECTOR. Then the name SIMPLE-BASE-STRING is also needed for
convenient type declarations of the more efficient but less functional
string representation. That name is good, by analogy to BASE-CHARACTER.
Adopting the above suggestions helps you decide what to do about the
SCHAR, SBCHAR, and SGCHAR mess. First of all, you only need two functions,
not three, because there are only two specified specialized representations.
SCHAR should be for what I've called SIMPLE-STRING, SBCHAR should be
for SIMPLE-BASE-STRING, and SGCHAR is not needed. (In fact I would prefer
to remove all of the specialized versions of AREF from the language, in
favor of THE or type declarations, but I know that would only pass over
some peoples' dead bodies so I won't push it.)
In case you are wondering, I have no quarrel with the name BASE-CHARACTER
and would not want to see it removed. I guess I differ from Larry here,
unless I erred when I wrote down his comments during the meeting.
Page 25 -- The discussion of STRING and SIMPLE-STRING thinks that there
is a distinction between declaration and discrimination, but Common Lisp
no longer has such a distinction. Even when Common Lisp did have such
a distinction, the meanings for declaration stated here were incorrect.
Page 29 -- *all-character-registry-names* has to be a variable, not a
constant, to accomodate systems (such as Symbolics Genera) that allows
dynamic addition of character registries by third-party software vendors
and by users.
Page 35 -- CHAR-REGISTRY should be renamed to CHAR-REGISTRY-NAME, so that
if at some later time character registry objects are added, there is no
possibility of confusion about whether this function returns a name or
an object.
Page 40 -- the default :ELEMENT-TYPE for OPEN cannot be BASE-CHARACTER. I
think this was discussed at the X3J13 meeting. The report suffers from a
confusion between two meanings of BASE-CHARACTER: the character type
implemented most efficiently by the Lisp, and the character type most
natural to the file system. These are not always the same. Furthermore,
in a network-based system that supports multiple file systems equally
(Symbolics Genera is an example), each file system might have a different
natural character type. BASE-CHARACTER should just mean the character type
implemented most efficiently by the Lisp. The default for :ELEMENT-TYPE
has two viable choices that I can see, and maybe you should just propose
both and let people vote:
(1) CHARACTER. This matches the behavior of MAKE-STRING and friends,
adheres to the principle that writing correct programs should be easier
than writing extra-efficient programs (since making a program correct
requires making every part of it correct, while making a program
efficient only requires improving the bottlenecks), and doesn't cost
anything in implementations that don't have extended characters.
(2) The most natural type for the particular pathname being opened.
In some systems this would be a constant, and in a subset of those
systems this would be BASE-CHARACTER, however in general this might
depend on the host, device, or even type fields of the pathname,
and might also depend on information stored in the file system.
In general this would always be an (improper) supertype of
BASE-CHARACTER, but it's probably a bad idea to make that a requirement,
as some file systems might not be able to implement it conveniently.
Again this doesn't cost anything in implementations that don't have
extended characters.
The relationship of option 2 to :ELEMENT-TYPE :DEFAULT (a feature that
already exists in Common Lisp) needs to be clarified. Perhaps they
are the same.
Also the following promise from 14 November did not show up in the report:
>> There should be a name for the "natural" encoding and there should be a
>> specification of the properties of the natural encoding that a programmer
>> can rely on. Suggestions for the name include :BASE, :NATURAL, and
>> :INTERCHANGE. The definition probably involves the concept of data
>> interchange with non-Lisp programs on the same system.
This will be added to the revision.
Appendix B -- I disagree with the way you've used deprecation. I'll
comment on each individual point:
- I see no justification for deprecating STANDARD-CHAR.
- I agree that STRING-CHAR should be deprecated, not deleted nor kept.
- I think fonts and bits should be removed outright, not deprecated,
because no portable program could possibly be using them.
- I think the CHAR-INT function needs to be kept, although the INT-CHAR
function should go away. This is for hashing. See comments below
on character attributes.
No particular page -- the use of strings for naming registries, labelling
characters, and naming external code formats is objectionable. Nothing
else in Common Lisp is named by strings. Use of strings might lead to
efficiency problems. We feel that keyword symbols are the appropriate
objects to use for these three kinds of names.
No particular page -- We agree with the deprecation or deletion of the two
particular character attributes defined by CLtL, but not with the
deprecation of the whole concept of character attributes. In fact on page
20 you say "characters are uniquely distinguished by their codes," which
makes it impossible to have character attributes at all. The language must
define how conforming programs should be written so that they will work
both in implementations with character attributes and in implementations
without them. For example, the value of (eql x (code-char (char-code x)))
is unspecified. Another thing that needs to be said is that the exact
character operations (char=, string=, etc.) respect all character
attributes, while the inexact character operations (char-equal,
string-equal, etc.) respect or ignore each character attribute in an
implementation-defined but consistent fashion. Some of what you say on
page 44 about attributes in general needs to be part of the spec, not
deprecated. I would retain everything on that page except for INT-CHAR and
the last bullet (referring to bits and fonts), and I would add a remark
that FIND-SYMBOL and INTERN respect character attributes. If you want,
perhaps I or someone else at Symbolics can provide exact text for what
to say about character attributes that you could insert into your report.
No particular page -- On the subject of defining character registries in a
separate document, and relating them to ISO standards for character
encoding: I think that's fine. I don't see anything wrong with introducing
the concept of character registry and the requirement that each character
object relates to exactly one registry. However, I think the somewhat
random list of character registries on pages 7-8 and again on page 21 does
not belong in the language specification. Even the names of the
standardized character registries belong in the character registry
standard, not in the Common Lisp language standard. I'm confused about the
meaning of BASE, STANDARD, and CONTROL as character registry names; these
are mentioned in your report but not explained very well. If these are
character registries that are required to exist in all Common Lisp
implementations, then unlike the others they do belong in the Common Lisp
language standard, not in the character registry standard.
At the meeting there was some discussion about the issue of enumerating all
characters in a character registry. People claimed incorrectly that it was
impossible. In fact it's possible to do this, with questionable
efficiency, by the following program:
(dotimes (code char-code-limit)
(let ((char (code-char code)))
(when char
(when (eq (char-registry-name char) desired-registry-name)
... process this char ...))))
Of course you have to change the EQ to EQUALP if you continue to use
strings to name character registries. For more efficiency, you could add
a way to iterate over all the codes in one character registry, but I think
that is unnecessary.
TYPOS:
25 -- base-string is missing from the Table 4-1 amendment.
26 -- general-string is not an array of BASE characters, also the first
two paragraphs under A.4.8 are garbled (the two separate sentences for
strings for symbols got smushed together).
37 -- This says the default for the :ELEMENT-TYPE option to MAKE-STRING
is SIMPLE-STRING. Actually it's CHARACTER.
VOTING:
You asked for suggestions on how to modularize the voting. Here is a
possible breakdown into separate issues, admittedly not very well thought
out. In general, I feel that breaking down the voting into separate issues
is a good idea even if some of the issues are interdependent. If people
don't understand the interdependencies well enough to vote properly, then I
would claim that the subcommittee report hasn't explained things well
enough.
Concept of character registries and character labels
Functions and variables for character registries and character labels
Page 9 rules for implementation-defined character registries
New syntax for #\
New syntax for the CHARACTER type specifier, new argument to CHARACTERP
New rules for names of symbols
Deprecation of STRING-CHAR
Deprecation of STANDARD-CHAR
BASE-CHARACTER type
New meaning of STRING type, and its subtypes
SCHAR
SBCHAR
SGCHAR
Type returned by (CONCATENATE 'STRING ...) and similar forms
Extensions to COERCE
EXTERNAL-WIDTH function
:ELEMENT-TYPE option to OPEN
:EXTERNAL-CODE-FORMAT option to OPEN
CHAR-CODED-CHARACTER-SET-VALUE function
Rules for implementation-defined character attributes
Removal or deprecation of bits and fonts, and implied arglist changes
Removal or deprecation of the semi-standard format effector characters
Support of extended characters in the readtable
Removal or deprecation of CHAR-INT
Removal or deprecation of INT-CHAR
Miscellaneous other and editorial changes
Wow, 26 ballot items! Democracy on the march! I think the complexity of
the issues amply justifies having about that many separate issues, though.
∂24-Jan-89 1312 CL-Characters-mailer Comments on the Character proposal dated January 1, 1989
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 24 Jan 89 13:12:07 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 24 Jan 89 15:47:56 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 24 Jan 89 16:08:30 EST
Date: Tue, 24 Jan 89 16:09 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Comments on the Character proposal dated January 1, 1989
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: Thom Linden <Baggins@ibm.com>, CL-Characters@sail.stanford.edu,
X3J13@sail.stanford.edu,
Common-Lisp-Implementors@stony-brook.scrc.symbolics.com,
KMP@stony-brook.scrc.symbolics.com,
Palter@stony-brook.scrc.symbolics.com
In-Reply-To: <19890124194625.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <19890124210921.6.BARMAR@OCCAM.THINK.COM>
Date: Tue, 24 Jan 89 14:46 EST
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
No particular page -- the use of strings for naming registries, labelling
characters, and naming external code formats is objectionable. Nothing
else in Common Lisp is named by strings. Use of strings might lead to
efficiency problems. We feel that keyword symbols are the appropriate
objects to use for these three kinds of names.
I agree with your suggestion. However, there is at least one global
database in CL that is named by strings: the package name database.
barmar
∂24-Jan-89 1325 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Sorting on NxN Mesh.
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Jan 89 13:24:57 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU (5.59/25-eef) id AA03811; Tue, 24 Jan 89 13:24:02 PDT
Message-Id: <8901242124.AA03811@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 24 Jan 89 13:23:04 PST
Received: by BYUADMIN (Mailer R2.01A) id 8345; Tue, 24 Jan 89 14:22:04 MST
Date: Tue, 24 Jan 89 14:00:49 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Math Dept U of Crete Greece Michalis Kolountzakis
<KOLOUTSAKIS%GRCRVAX1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Math Dept U of Crete Greece Michalis Kolountzakis
<KOLOUTSAKIS%GRCRVAX1.BITNET@forsythe.stanford.edu>
Subject: Sorting on NxN Mesh.
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
I would appreciate any suggestions, references or solutions for the following
problem:
We have a SIMD, 4-connected, NxN Mesh Connected Computer (MCC) and
the following
algorithm for sorting on it. The algorithm is an extension of the
so called "odd-even transposition sorting" (OETS) algorithm for a
sequence of N processors:
P <--> P <--> P <--> ... <--> P
0 1 2 N-1
OETS works by coupling all processors and performing a compare-and-
then-possibly-swap operation on every pair of processors. In even
time moments the set P={0,...,N-1} is partitioned in
{(0,1), (2,3), ..., (2i,2i+1), ...} and in odd time moments P is parti-
tioned in {(1,2), (3,4), ..., (2i-1,2i) ,...} (P and P are not always
0 N-1
in some pair). It is almost obvious that OETS is a sorting algorithm
for the sequence of processors but it takes some time to prove that it
is linear in N. So, in OETS, each prossesor compares its contents, first
with its left neighbour and then with its right neighbour and so on.
In two dimensions the most reasonable extension of OETS would be to
couple each processor first with its upper neighbour, then with its
lower, its left and finally irs right neighbour and perform a compare-
and-then-possibly-swap operation. More precisely in time T the NxN
grid G={(i,j): i, j in P /* i for rows */} is partitioned in
{ <(2i-1,j), (2i, j)> for all i, j } when T mod 4 = 0
{ <(2i,j), (2i+1,j)> for all i, j} when T mod 4 = 1
{ <(i,2j-1), (i,2j)> for all i, j} when T mod 4 = 2 and
{ <(i,2j), (i,2j+1)> for all i, j} when T mod 4 = 3,
and all these pairs of processors compare their contents and possibly
swap them.
It is obvious again that it is a sorting algorithm but what is its
time complexity? Is it linear ? is the question. I suspect it is not,
because if it were no other sorting alg. for the NxN mesh should have
been invented; this seems far simpler than any other I have seen.
But I do not have a bad example for this alg. Do you?
Thanks in advance
Michalis Kolountzakis,
Mathematics Dept, Univ. of Crete, Greece
e-mail: koloutsa@grcrvax1.bitnet
------------------------------------------------------------------------
Date: Tue, 24 Jan 89 21:28 O
From: Michalis Kolountzakis(Math Dept U of Crete Greece)
<KOLOUTSAKIS@GRCRVAX1>
Subject: More on sorting on the NxN mesh
To: theorynt@ndsuvm1
On the problem I have just mailed to the list (Sorting on the Mesh Connected
Computer) I have not given the desirable order on the Mesh for which the
algorithm I have described is supposed to work. I cannot expect this order
to be any one for which "local order" does not imply "global order", e.g. it
cannot be the row-major (lexicographic) order. If we want big elements to go
up and left, then the following configuration of values
4 2
3 1
for a 2x2 Mesh is not ordered (2 and 3 should be swapped) but it is locally
consistent with the row-major order (that is, every element in the Mesh is
consistent with its neighbours.)
An order for the Mesh which is good for our purposes is the "snake-like"
order for which such a configuration cannot exist and so we can prove that the
proposed algorithm is indeed a sorting algorithm.
Michalis Kolountzakis,
Math. Dept, Univ. of Crete, Greece
∂24-Jan-89 1736 misha@polya.Stanford.EDU This week's AFLB
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Jan 89 17:36:26 PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA22830; Tue, 24 Jan 89 17:33:42 PDT
Date: Tue, 24 Jan 89 17:33:42 PDT
From: Michael Kharitonov <misha@polya.Stanford.EDU>
Message-Id: <8901250133.AA22830@polya.Stanford.EDU>
To: aflb-all@polya.Stanford.EDU
Subject: This week's AFLB
Eva Tardos will speak on Thursday, January 26, at 12:30 pm
in room 352. She will speak on:
Combinatorial algorithms for the generalized network flow problem
We consider a generalization of the maximum flow problem in which
the amounts of flow entering and leaving an arc are linearly related.
More precisely, if $x(e)$ units of flow enter an arc $e$,
$x(e) \gamma (e)$ units arrive at the other end.
For instance, nodes of the graph can correspond
to different currencies, with the multipliers being the exchange rates.
We require conservation of flow at every node except a given source
node. The goal is to maximize the amount of flow excess at the source.
This problem is a special case of linear programming, and therefore
can be solved in polynomial time.
We present a simple combinatorial algorithm for this problem, that is based
on ideas from maximum flow and minimum cost flow algorithms.
Joint work with Andrew Goldberg and Serge Plotkin.
∂24-Jan-89 1949 @Score.Stanford.EDU,@polya.Stanford.EDU:hayes@arisia.xerox.com teaching strategies
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Jan 89 19:49:18 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 24 Jan 89 19:46:22-PST
Received: from arisia.Xerox.COM by polya.Stanford.EDU (5.59/25-eef) id AA29380; Tue, 24 Jan 89 19:47:33 PDT
Received: by arisia.Xerox.COM
(5.59++/IDA-1.2.6) id AA29402; Tue, 24 Jan 89 19:46:05 PST
Date: Tue, 24 Jan 89 19:46:05 PST
From: Pat Hayes <hayes@arisia.xerox.com>
Message-Id: <8901250346.AA29402@arisia.Xerox.COM>
To: faculty@Polya.Stanford.EDU
Cc: hayes.pa@Xerox.COM
Subject: teaching strategies
The discussion this lunchtime on the role of courses, research and
quals in the PhD program stimulated some thoughts. It seems clear
that there are some quite profound differences among what some of the
senior faculty regard
The views expressed by Ed Feigenbaum and Bob Floyd this lunchtime
represented two positions which often arise in discussions of how to
do graduate teaching. It is the difference between thinking of a PhD
as primarily an apprenticeship to research, or as a certification in
professional competence. Of course, these are not incompatible; and
indeed if the competence in question is that of being a researcher,
then they should coincide. But since the world is less than perfect,
compromises are necessary, and ones willingness to compromise depends
on ones perspective.
According to the first view, graduate school is learning to do
research. To do this well requires a wide and sometimes deep knowledge
of the subject, of course, but chiefly it requires a certain skill
which - as Ed emphasises - can best be obtained by working closely
with active researchers. ( I chose the word "apprenticeship"
carefully, since the closest analogy is with the mediaeval craft
guilds. One cant learn how to be a smith by attending courses, one
has to work with iron. ) Part of this skill is, arguably, the ability
to bone up on the literature in some local area when it seems relevant
to ones work, so that rather than trying to know it all, one should
have a sort of perspective on the main ideas and an active curiosity.
On the second view, however, its not our job to make our students into
anything in particular, but rather to make sure that they have, and
can use, all the knowledge and abilities which a competent
professional computer scientist should have at their fingertips. Its
more like training a medical doctor, where the chief failing would be
simple ignorance of some vital part of the subject. Faculty members
have expressed this idea to me forcibly in the past.
Those who take the second perspective on graduate teaching often see
the PhD as a sort of stamp of approval, and so are especially anxious
that it not be applied to anyone who doesnt meet the professional
criteria to which the school adheres. To do so would be
irresponsible, and in the long run would simply devalue the schools
reputation in the professional community. This sort of view tends to
lead to the raising of qualification barriers of one sort or another.
But this is far less important to someone who thinks in terms of
research apprenticeship. After all, the performance of a scientist
cannot be predicted on the basis solely of what they do in graduate
school, and credit for their subsequent career performance must be
largely given to the individual in question. All that the school
certifies is that they have done a piece of genuine research - their
dissertation.
Now these are both extreme positions I have outlined, and most people
think that graduate school has something of both - and probably other
- roles to play. But I think it might be worth keeping these sort of
issues clear, because what seem to be disagreements about methods
might in fact be differences about goals.
Pat Hayes
∂25-Jan-89 0613 X3J13-mailer Issues DECLARATION-SCOPE and DEFINING-MACROS-NON-TOP-LEVEL
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 25 Jan 89 06:13:30 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00927g; Wed, 25 Jan 89 06:07:03 PST
Received: by bhopal id AA08310g; Wed, 25 Jan 89 06:09:24 PST
Date: Wed, 25 Jan 89 06:09:24 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901251409.AA08310@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: sandra%defun@cs.utah.edu, X3J13@sail.stanford.edu
In-Reply-To: David A. Moon's message of Mon, 23 Jan 89 13:49 EST <19890123184939.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issues DECLARATION-SCOPE and DEFINING-MACROS-NON-TOP-LEVEL
re: The problem is that (LOCALLY (DECLARE ...) (DEFUN ...)) cannot be used as
the new way to say what used to be said as (DEFUN ... (DECLARE ...) ...),
even though side-discussion at the meeting indicated that some people
I didn't hear any of this "side discussion", but I can imagine it
happening. Actually, there might be less need for declarations that
apply to the whole defun than one might expect (but of course
there would some extreme cases where it is very cumbersome not
to have it). A "cumbersome" workaround is to wrap LOCALLY's
around all the defaulted computations in the &optional and &key
parameters, as well as having a regular declare in the DEFUN.
This style of "cumbersome" workaround _was_ mentioned in the
discussion section of the proposal:
One idiom which will be adversely affected by both of these proposals is:
(let ((*a* *a*))
;; rebind *a* to it's "old" value
(declare (special *a*))
...)
where *a* has not been proclaimed special. This idiom would likely
have to be written as:
(let ((*a* (locally (declare (special *a*)) *a*)))
;; rebind *a* to it's "old" value
(declare (special *a*))
...)
or [preferably!] *a* should be proclaimed special. Similar idiots
like this may be in use for LAMBDA-Expressions, or DEFUNs etc.
[sic. Hopefully, someone will correct the typo before it gets into
the standard]
This problem *was* discussed at some length about a year ago --
I recall KMP bringing it up, and I explicitly mentioned it to
you (maybe in that series of private interchanges we had on
the issue). Your reply to me looked as though you didn't
appreciate the problem back then. [If you are concerned about
the exact wordings, I could probably rummage around in old mail
files . . . ]
One problem with trying to say that LOCALLY "passes through"
top-level is that in fact it carries a non-null (syntatical)
lexical environment. If we remember Walter van Roggen's proposal
from long ago to say that "toplevel" merely means null lexical
environment, then LOCALLY won't make it. Consider for example
how the following functions work interpretively:
(defun bar (x) (macrolet ((flower (z) `(quote ,z)))
#'(lambda (y) (if y (flower x) 5))))
(defun baz (x) (locally (declare (special x ))
#'(lambda (y) (if y (flower x) 5))))
Several implementations I've tried BAR on seem to do it right;
maybe not so many will do BAZ right.
Now, I don't mind saying that the "special attention" paid
to top-level forms should also be paid to certain forms
in embedded places. It just seems that the notion "toplevel"
is becoming more and more artificial, and less related to
what the intuitive notion implies. It's possible that the
very complicated notion that Rob McLaughlin once tried to
espouse may be necessary to explain all this.
-- JonL --
∂25-Jan-89 0850 X3J13-mailer Issues DECLARATION-SCOPE and DEFINING-MACROS-NON-TOP-LEVEL
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 25 Jan 89 08:50:26 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 526603; Wed 25-Jan-89 11:48:00 EST
Date: Wed, 25 Jan 89 11:48 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issues DECLARATION-SCOPE and DEFINING-MACROS-NON-TOP-LEVEL
To: Jon L White <jonl@lucid.com>
cc: sandra%defun@cs.utah.edu, X3J13@SAIL.STANFORD.EDU
In-Reply-To: <8901251409.AA08310@bhopal>
Message-ID: <19890125164831.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 25 Jan 89 06:09:24 PST
From: Jon L White <jonl@lucid.com>
If we remember Walter van Roggen's proposal
from long ago to say that "toplevel" merely means null lexical
environment, then LOCALLY won't make it.
But (when (oddp (random))
(defmacro frob ...))
clearly evaluates the defmacro in a null lexical environment, and just
as clearly does not have the defmacro in a top-level position.
∂25-Jan-89 0936 X3J13-mailer Issues DECLARATION-SCOPE and DEFINING-MACROS-NON-TOP-LEVEL
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 25 Jan 89 09:36:00 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Wed, 25 Jan 89 12:11:19 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Wed, 25 Jan 89 12:31:53 EST
Date: Wed, 25 Jan 89 12:32 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issues DECLARATION-SCOPE and DEFINING-MACROS-NON-TOP-LEVEL
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: Jon L White <jonl@lucid.com>, sandra%defun@cs.utah.edu,
X3J13@sail.stanford.edu
In-Reply-To: <19890125164831.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <19890125173236.0.BARMAR@OCCAM.THINK.COM>
Date: Wed, 25 Jan 89 11:48 EST
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Date: Wed, 25 Jan 89 06:09:24 PST
From: Jon L White <jonl@lucid.com>
If we remember Walter van Roggen's proposal
from long ago to say that "toplevel" merely means null lexical
environment, then LOCALLY won't make it.
But (when (oddp (random))
(defmacro frob ...))
clearly evaluates the defmacro in a null lexical environment, and just
as clearly does not have the defmacro in a top-level position.
I think JonL meant that toplevel implies null lexical environment, not
the other way around.
barmar
∂25-Jan-89 1320 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Forsythe Lectures/Ruzena Bajcsy
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Jan 89 13:20:38 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 25 Jan 89 13:17:08-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA05247; Wed, 25 Jan 89 13:18:20 PDT
Date: Wed, 25 Jan 1989 13:18:17 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score
Subject: Forsythe Lectures/Ruzena Bajcsy
Message-Id: <CMM.0.87.601766297.chandler@polya.stanford.edu>
Professor Bajcsy will be here February 14 and I'll be working with her to set
up a schedule. If you would like to chat with her please contact me and I'll
put a tentative schedule together.
∂25-Jan-89 1555 snoeyink@polya.Stanford.EDU Next BATS
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Jan 89 15:54:56 PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA15568; Wed, 25 Jan 89 15:53:55 PDT
Date: Wed, 25 Jan 89 15:53:55 PDT
From: Jack Snoeyink <snoeyink@polya.Stanford.EDU>
Message-Id: <8901252353.AA15568@polya.Stanford.EDU>
To: aflb-local@polya.Stanford.EDU
Subject: Next BATS
Advance Notice: The next BATS will be held at Berkeley on Feb 10.
∂25-Jan-89 1732 emma@csli.Stanford.EDU CSLI Calendar, January 26, 4:13
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Jan 89 17:32:14 PST
Received: by csli.Stanford.EDU (4.0/inc-1.0)
id AA22128; Wed, 25 Jan 89 16:36:02 PST
Date: Wed, 25 Jan 89 16:36:02 PST
From: emma@csli.Stanford.EDU (Emma Pease)
Message-Id: <8901260036.AA22128@csli.Stanford.EDU>
To: friends@csli.Stanford.EDU
Subject: CSLI Calendar, January 26, 4:13
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
26 January 1989 Stanford Vol. 4, No. 13
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR THIS THURSDAY, 26 January 1989
12 noon TINLunch
Cordura Hall Guarded Horn Clauses: Language Design and Future
Conference Room Directions
Kazunori Ueda
ICOT
3:30 p.m. Tea
Ventura Hall
____________
THIS WEEK'S TINLUNCH
Guarded Horn Clauses: Language Design and Future Directions
Kazunori Ueda
ICOT
January 26
Guarded Horn Clauses (GHC) is a logic programming language for
describing concurrent processes. The talk will introduce the purposes
and the motivations of the language and then give a simple trace set
semantics of it. The talk will be concluded by suggesting future
research directions.
____________
LINGUISTICS DEPARTMENT COLLOQUIUM
Free Word Order Structures as Evidence for a
Restrictive Theory of Parameters
Gert Webelhuth
University of Massaschusetts, Amherst
Friday, 27 January, 4:15
Cordura Conference Room
The talk will consist of two parts. In the first half, it will be
shown that the pro-drop, wh-movement, and directionality parameters
can be stated in such a way that they all share certain properties. It
will then be argued that the common properties should be extracted
from the individual formulations and be derived from the overall
organization of Universal Grammar, so that all (morphosyntactic)
parameters of natural language can be subjected to them. The result is
a principles and parameters framework where the power of parameters is
constrained in a fashion similar to the restrictions imposed on phrase
structure configurations by X-bar theory.
The second half of the talk will extend the scope of the above
mentioned theory of parameters to the configurationality parameter. It
will be demonstrated that German, as such a free word order language,
displays severe constraints on the availability of free word order
structures. In particular, a comparison with wh-movement will show
that free word order sentences obey eleven different constraints on
wh-movement (e.g., the Subject Condition), arguing that German is not
a free word order language in the sense of a W* approach but rather in
the same sense in which it can be said that German and English are
wh-movement languages. In a final step a number of pragmatic
properties of free word order structures are addressed.
It will be concluded that if the approach to free word order in
this talk can be carried over to other languages, then the
configurationality parameter also satisfies the general constraints on
parameters mentioned earlier, so that four important parameters will
have been shown to be subject to these universal constraints:
pro-drop, wh-movement, directionality, and the configurationality
parameter.
-----------
SYMBOLIC SYSTEMS FORUM
Quantification in Natural Language
Peter Sells
Dept. of Linguistics, Stanford
Friday, 27 January, 3:15
Room 60:61N
In this talk I'd like to look at the relation between a first-order
logic style representation for quantification and the way that
quantificational structures are manifest in natural languages, and the
way in which that interacts with other "variable"-like elements in
natural language, such as pronouns. There has been quite a lot of
work in recent years on existential quantification in natural
languages, which seems to diverge quite a lot from the picture you
would expect from standard logic, and I'll probably concentrate on
that, using data from English and Japanese.
Structure Yes, Symbols No
Jerome A. Feldman
Friday, 3 February, 3:15
Room 60:61G
Computer Science, Artificial Intelligence and many related fields have
followed symbol-processing paradigms almost without exception. Recent
work has suggested alternative views of intelligent activity based on
connectionist (or PDP or `neural') networks. This talk will discuss a
"structured" connectionist approach that attempts to capture the best
features of symbolic and neural-style computation. After some
preliminaries, the talk will focus on a connectionist model of visual
recognition, which is claimed to be (the only model) consistent with
the relevant biological, behavioral, and computational findings.
Finally, we will try to indicate what this model suggests about how
intelligence is realized in animals and artifacts.
∂26-Jan-89 0002 X3J13-mailer Re: Comments on the Character proposal dated January 1, 1989
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 26 Jan 89 00:02:45 PST
Received: from Semillon.ms by ArpaGateway.ms ; 25 JAN 89 23:59:20 PST
Date: 25 Jan 89 23:57 PST
From: masinter.pa@Xerox.COM
Subject: Re: Comments on the Character proposal dated January 1, 1989
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Tue, 24 Jan 89 14:46 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: X3J13@SAIL.STANFORD.EDU,
Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM,
KMP@STONY-BROOK.SCRC.Symbolics.COM, Palter@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <890125-235920-8229@Xerox>
David,
I thought there were fewer than 26 "issues". I thought they might be split
up into issues as follows; I think these issues 'cover' the current
proposal with some exceptions. I've enclosed David's characterization of
the issues in <brackets>; as you see, I've lumped some of them together.
Exceptions:
<New rules for names of symbols.> What new rules?
<:ELEMENT-TYPE option to OPEN.> I thought this was removed from the
proposal.
<Removal or deprecation of the semi-standard format effector characters.> I
guess I don't understand this.
<Support of extended characters in the readtable.> I thought this falls out
of character type?
<Miscellaneous other and editorial changes> not sure what they are...
Sorry that the following are telegraphic. I'd guess they would need to be
fleshed out more.
!
Issue: CHAR-FONT-UNUSED
Problem: CHAR-FONT isn't used, CHAR-BITS isn't portable.
Proposal: eliminate of CHAR-FONT and CHAR-BITS, related parameters, and the
STRING-CHAR type. (I.e., identification of STRING-CHAR with CHARACTER).
<Removal or deprecation of bits and fonts, and implied arglist changes.
Deprecation of STRING-CHAR. Removal or deprecation of CHAR-INT. Removal or
deprecation of INT-CHAR. Rules for implementation-defined character
attributes.>
If this fails, or if people only wanted to eliminate CHAR-FONT and not
CHAR-BITS, most of the rest of the proposals get more complicated.
Issue: STRING-TYPE-RESTRICTIVE
Problem: STRING type doesn't allow thin & fat strings.
Proposal: change to the STRING type to be "all vectors with element type a
subtype of CHARACTER" rather than (VECTOR CHARACTER). Specify the
(modified) behavior of various functions that take a type specifier when
given STRING.
<New meaning of STRING type, and its subtypes. Type returned by
(CONCATENATE 'STRING ...) and similar forms. Extensions to COERCE.>
Issue: STRING-TYPE-ABBREVIATIONS
Problem: new types are awkward to name, want abbreviations.
Proposal: add convenient abbreviations for string types & accessors. Define
BASE-CHARACTER = (UPGRADED-ARRAY-ELEMENT-TYPE 'STANDARD-CHAR). Add SCHAR
SBCHAR SGCHAR BASE-STRING MOST-GENERAL-STRING SIMPLE-GENERAL-STRING
SIMPLE-BASE-STRING etc.
<SCHAR. SBCHAR. SGCHAR. BASE-CHARACTER type. Deprecation of STANDARD-CHAR.>
Issue: FILE-EXTERNAL-REPRESENTATION
Problem: can't specify external encoding even when there are lots
Proposal: add standard :EXTERNAL-CODE-FORMAT keyword to OPEN, with
unspecified range.
<:EXTERNAL-CODE-FORMAT option to OPEN>
Issue: CHARACTER-IDENTIFICATION-NONPORTABLE
Problem: Can't portably talk about non-standard characters
Proposal: introduce the notion of Registries, require a fixed set of
registries, standardize on #\registry:id, add all-implemented-registries
and find-character.
This part deals with the mechanism by which characters can be identified
portably between implementations that do not share the same coded character
set.
<Concept of character registries and character labels
Functions and variables for character registries and character labels
Page 9 rules for implementation-defined character registries
New syntax for #\
New syntax for the CHARACTER type specifier, new argument to CHARACTERP
>
Issue: CHARACTER-FUNCTIONS-UNDERSPECIFIED
Problem: how ALPHA-CHAR-P, LOWER-CASE-P work on Kanji, characters with
accents, etc. is not specified.
Proposal: Current proposal is to leave unspecified.
I'd rather specify the 'intent' of the behavior of ALPHA-CHAR-P,
LOWER-CASE-P etc for alphabetic and non-alphabetic scripts (e.g., works for
Greek, no-op for Hangul, etc.)
< Not in current list >
Issue: STRING-BINARY-WIDTH
Problem: Can't find out how many bytes a string will take when written as
text
Proposal: <EXTERNAL-WIDTH function>
Issue: CHAR-CODE-NON-PORTABLE
Problem: no way to talk about well-known external coding methods, only
internal codes
Proposal: Add CHAR-CODED-CHARACTER-SET-VALUE
<CHAR-CODED-CHARACTER-SET-VALUE function.>
∂26-Jan-89 0920 TAJNAI@Score.Stanford.EDU book signing at the Forum annual meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 89 09:20:04 PST
Date: Thu 26 Jan 89 09:14:47-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: book signing at the Forum annual meeting
To: faculty@Score.Stanford.EDU
cc: hiller@Score.Stanford.EDU
Message-ID: <12465659865.15.TAJNAI@Score.Stanford.EDU>
Roy Hoyer of the Stanford Bookstore, and I invite
authors, who have published a book since the February 1988 meeting,
to have a book signing from 3 to 4 Wednesday, Feb. 15.
If you like, you may also place 2 or 3 books on the registration table to
give the attendees an advance glance.
Let me know by January 31, and arrangements will be made according to
book availability.
Each year the Bookstore arranges a 10% promotion on computer science books
during Forum week. This sounds like fun! Lunch will be at Tresidder, and
poster sessions will be held in CERAS from 1:30 to 4:00, so the traffic will
be around the Bookstore area.
So let me know, and I'll take it from there........
Carolyn
-------
∂26-Jan-89 0924 @Score.Stanford.EDU:goldberg@Jinn.stanford.edu Industrial Lecturer Appointment
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 89 09:24:28 PST
Received: from Jinn.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 26 Jan 89 09:15:07-PST
Received: by Jinn.stanford.edu (4.0/25-eef) id AA15701; Thu, 26 Jan 89 09:16:03 PST
Date: Thu, 26 Jan 89 09:16:03 PST
From: Andrew Goldberg <goldberg@Jinn.stanford.edu>
Message-Id: <8901261716.AA15701@Jinn.stanford.edu>
To: faculty@score
Subject: Industrial Lecturer Appointment
The Visiting Prof. Committee is considering appointing Douglas Lenat
as an Industrial Lecturer for the next year. Many of you know
him, both because of his work and because he was at Stanford for
several years.
Doug Lenant's resume is available from Rosemary Napier, MJH 340, for
any faculty member who wants to look at it.
--Andy
∂26-Jan-89 1349 GENESERETH@Score.Stanford.EDU Re: Industrial Lecturer Appointment
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 89 13:49:45 PST
Date: Thu 26 Jan 89 13:45:08-PST
From: Mike Genesereth <GENESERETH@Score.Stanford.EDU>
Subject: Re: Industrial Lecturer Appointment
To: goldberg@Jinn.Stanford.EDU
cc: faculty@Score.Stanford.EDU
In-Reply-To: <8901261716.AA15701@Jinn.stanford.edu>
Message-ID: <12465709081.31.GENESERETH@Score.Stanford.EDU>
Andy,
This seems inappropriate, since we just appointed hi a consulting
professor. Yes, it would be nice to have him give some lectures,
but his lectuires were one of the bases on which we made the
consulting propfessor appointment. Since he is already affiliated
with the department, what is the additional advantage of this
appointment?
mrg
PS Don't read anything between the lines here. Doug is a friend,
and I am interested in taking a look at his recent work. My
comment should be taken at face value. I odn't understand the
rationale for this proposal.
-------
∂26-Jan-89 1352 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Combinatorial Enumeration Question
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 89 13:51:55 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA03712; Thu, 26 Jan 89 13:50:59 -0800
Message-Id: <8901262150.AA03712@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Thu, 26 Jan 89 13:48:42 PST
Received: by BYUADMIN (Mailer R2.01A) id 4047; Thu, 26 Jan 89 14:47:06 MST
Date: Thu, 26 Jan 89 14:27:59 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
David Jones <djones@POLYA.STANFORD.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: David Jones <djones@POLYA.STANFORD.EDU>
Subject: Combinatorial Enumeration Question
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
I would very much appreciate any leads people can give me on
the following question:
How many non-isomorphic X's are there of order N?
where X= { group, graph }
Since I doubt the answers are known in general form, I'd be pleased
with bounds, or answers for particular values of N - say up to 10.
Please reply directly to:
djones@polya.stanford.edu
∂26-Jan-89 1403 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu TCS day at Maryland
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 89 14:03:49 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA04636; Thu, 26 Jan 89 14:02:56 -0800
Message-Id: <8901262202.AA04636@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Thu, 26 Jan 89 14:01:55 PST
Received: by BYUADMIN (Mailer R2.01A) id 4626; Thu, 26 Jan 89 14:58:24 MST
Date: Thu, 26 Jan 89 14:07:57 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Uzi Vishkin <vishkin@UZISUN.UMIACS.UMD.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Uzi Vishkin <vishkin@UZISUN.UMIACS.UMD.EDU>
Subject: TCS day at Maryland
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
PRELIMINARY ANNOUNCEMENT
Theoretical Computer Science Day
Institute for Advanced Computer Studies
University of Maryland
College Park, MD
The University of Maryland Institute for Advanced Computer Studies
(UMIACS) is organizing a theoretical computer science day
on Monday, April 17, 1989.
PROGRAM
9:30 -9:50 - Refreshments
9:50 -10:00 - Greeetings
Larry S. Davis
Director, UMIACS
10:00-11:00 - Speaker: Zvi Galil
Columbia University and Tel Aviv University
Title: Sparse Dynamic Programming
11:00-12:00 - Speaker: S. Rao Kosaraju
Johns Hopkins University
Title: Selection by a tree of processors
12:00-2:00 - Lunch break
2:00 -3:00 - Speaker: Gary L. Miller
Carnegie-Mellon University and University of Southern California
Title: Parallel Algorithm Design for Planar Graphs
3:00 -4:00 - Speaker: Andrew C. Yao
Princeton University
Title: Boolean circuits and neural networks
4:15 -5:30 - Reception
PLACE: Center for Adult Education, University of Maryland, College Park.
DIRECTIONS: College Park is just outside of Washington, DC. It is about
10 miles from the Capitol. The Center for Adult Education is located on
the western edge of the College Park campus at the intersection of
Adelphi Road, University Boulevard (Maryland Route 193), and campus Drive.
To reach the Center from the Washington Beltway, take the Route 1
exit south to University Boulevard westbound.
If you have any questions or would like a map, please contact
Cecilia Kullman at (301) 454-1808 or by e-mail (cecilia@umiacs.umd.edu)
PLEASE POST
∂26-Jan-89 1444 TAJNAI@Score.Stanford.EDU Affiliates "Tax"
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 89 14:44:07 PST
Return-Path: <hellman@isl.Stanford.EDU>
Received: from isl.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 26 Jan 89 13:48:47-PST
Received: by isl.Stanford.EDU (3.2/4.7); Thu, 26 Jan 89 13:46:49 PST
Date: Thu, 26 Jan 89 13:46:49 PST
From: hellman@isl.Stanford.EDU (Martin Hellman)
To: leboeuf@sierra
Subject: Affiliates "Tax"
Cc: char@isl.Stanford.EDU, goodman@sierra, gray@isl.Stanford.EDU, inan@sierra,
pease@sierra, tajnai@score
ReSent-Date: Thu 26 Jan 89 14:39:49-PST
ReSent-From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
ReSent-To: faculty@Score.Stanford.EDU
ReSent-Message-ID: <12465719034.39.TAJNAI@Score.Stanford.EDU>
TO: Elliott Levinthal
Associate Dean for Research
FROM: Martin Hellman, Director Information Systems Lab, EE Dept.
I am responding to your memo on the possibility of taxing gift
and affiliate funds. I have attached the information you
requested at the end of this memo. I have also solicited input
from our faculty on this proposal and have incorporated their
input.
I think it is an excellent idea to review the whole question of
indirect costs. But the question of whether affiliate or gift
funds should be "taxed" needs to be dealt with along with the
question of whether contract and grant funds are being strangled
by overtaxation. I am attaching a copy of my memo of last
October 27 to Joe Goodman (copied to Jim Gibbons) which deals
with that issue.
A tax on affiliate funds would be particularly inappropriate and
galling because we use most of those funds to pay for things that
the university should pay for out of the overhead we already are
paying on our contracts and grants. For example, within the last
year, we used over $10k of our affiliate fund to pay for
maintenance of and improvement to our physical plant, which
clearly should be an overhead item. This year our normal
allocation from overhead for such expenses is only $900 for a
group of fifteen faculty, 75 grad students, six secretaries, plus
several research associates. Our annual sponsored research
budget is approximately $3 million which means that we
contributed over $1 million in overhead, and yet we are allocated
only $900 for furniture and physical plant maintenance. Clearly,
we have to augment these funds, as we have done. (The Dept and
School matched our funds, but I believe these too came from gift
funds, not overhead.)
I think you can imagine how we would feel at having to pay some
kind of overhead on affiliate funds that are used to pay for what
overhead should have paid for to begin with. From this end, a
lot of what is charged as overhead seems like a way for the
university to convert contract dollars into unrestricted funds,
as when a new building is paid for by a gift but depreciation on
that same building is then added to the overhead pool. Such
actions would not not be a problem if they had not been carried
to an extreme and resulted in an unbearable burden on our
faculty.
Gift funds are a slightly different matter. Some of them also
are used to pay for things that should be covered by overhead,
and taxing these would be just as inappropriate as taxing
affiliate funds. Other gift funds are close to contracts or
grants and, here, some kind of tax might be appropriate IF the
overhead charges to contracts and grants are reduced by the same
amount.
I know that accounting rules would theoretically require such a
reduction, but with the overhead rate reaching an embarrassing
level, I fear that taxing gift funds would be used as a way to
increase the "overhead take" without it appearing so bad. We
have reached such a ridiculous point that we cannot afford adding
to the overhead pool every expense which can be justified by
accounting rules. At some point, reason must prevail.
One of our faculty who is in the process of soliciting gift
support from industry asked me to note that he was told that the
gifts would be withdrawn if overhead or other taxes were added.
The perception of his donors seems to be that the university is
being greedy. (Another faculty member told me that DARPA is
complaining to him that their research dollar buys much less at
Stanford than at some other comparable institutions, notably
Berkeley, and that they might shift support accordingly.)
Another of our faculty felt that a small, perhaps 5%, "tax" on
gift funds used to support research might be appropriate but only
if the rate were guaranteed for a long period of time on the
order of ten years. He, along with many others, expressed
concern about the rate moving up rapidly once the precedent was
set. Looking at what has happened to overhead rates, I share
that concern.
I imagine that what I am proposing is not what the university had
in mind when it opened up the question of taxing gift funds. But
I hope that this memo explains why the broader issue is one that
must be addressed. Thank you.
Martin Hellman
Director, ISL
----- copy of my earlier memo of 10/27/88 to Prof. Goodman -----
To: goodman
Subject: overhead
Cc: gibbons@sierra
Bcc: faculty@isl
Oct 27, 1988
Dear Joe:
This message is a follow-up to our phone conversation of
yesterday evening concerning overhead rates. I have been
concerned with this issue for some time and, since becoming
Director of ISL earlier this year, I have been approached by a
number of faculty who also wished to bring it to my attention.
Basically, we are paying an outrageous overhead rate and getting
very little in return. Patience is wearing thin and, if things
continue along current lines, something will break. I know that
overhead funds have been a great asset to the university as a
whole and I do not wish to see that source of strength
eliminated. But there has to be a new sense of proportion and
reasonableness at all levels of the university.
The overhead percentage itself is quite high, but the real
overhead rate is even higher. In industry, overhead includes
copying, building repair and maintenance, postage and many other
things that we bill as direct costs. When all this is taken into
account, I would not be surprised if our overhead rate were
higher than many in industry.
To say the least, it is annoying when the faculty in our lab pay
over a million dollars a year in overhead to be expected to pay
for every little thing (e.g., new chairs to replace three that
are so badly broken they can't be sat on, window cleaning, rug
cleaning), or at a minimum, to have to make a case for Department
or School funds to be used for such small purchases.
I know the university must justify the full overhead percentage
to get the government approval. But, even if justified on
accounting grounds, one must look at reasonableness. For
example, the new building program is certainly needed. We
currently have research associates and visiting professors jammed
into grad student bull pens. But I do not believe it is right to
add the depreciation on new buildings into the overhead base if
they are paid for by gifts. That way the university gets the
money twice, first as a gift and again as overhead. If the
overhead rate were more reasonable, we might overlook such
accounting practices. But when the goose that lays the golden
egg is in danger of dying from exhaustion, it is time to think
differently.
Thanks very much for considering these thoughts.
Martin Hellman
Director, Information Systems Lab
------ Information Requested by Dean Levinthal ----------
I. Income:
a. Earnings last year $160,000
Current year estimate $220,000
b. 16 member companies last year
18 member companies this year
c. Annual fee $10,000
II. Allocations: (These are approximate averages per year.
Exact figures are difficult because of major variations from year
to year and other factors.)
a. General academic support: $10,000
b. Support of scheduled courses: $10,000
c. Administration of Program: $20,000
d. Group research support: $ 0
e. Individual faculty allocation: $50,000
f. Computers and maintenance: $50,000
g. Graduate Student support:
h. Visiting Scholars: $10,000
i. Physical plant maint & improvement: $10,000
∂26-Jan-89 1803 X3J13-mailer Re: Comments on the Character proposal dated January 1, 1989
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Jan 89 18:03:05 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 527962; Thu 26-Jan-89 21:00:31 EST
Date: Thu, 26 Jan 89 21:01 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Comments on the Character proposal dated January 1, 1989
To: masinter.pa@Xerox.COM
cc: X3J13@SAIL.STANFORD.EDU, Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM,
KMP@STONY-BROOK.SCRC.Symbolics.COM, Palter@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <890125-235920-8229@Xerox>
Message-ID: <19890127020101.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 25 Jan 89 23:57 PST
From: masinter.pa@Xerox.COM
<New rules for names of symbols.> What new rules?
There are several mentions of symbol names in the report, but maybe
those are just wording changes and nothing new. I think I was referring
mainly to the 8th and 9th bullets on p.44, relating to READ's handling
of implementation-defined character attributes.
<:ELEMENT-TYPE option to OPEN.> I thought this was removed from the
proposal.
Bottom of p.40, top of p.41. The terrible format of the proposal makes
it difficult to tell that these sections are referring to :element-type,
but they are.
You're probably thinking of the :character-set option to OPEN, which was
removed.
<Removal or deprecation of the semi-standard format effector characters.> I
guess I don't understand this.
Pages 19,37, 38 of the report and I think a couple of other pages as
well. CLtL p.21.
<Support of extended characters in the readtable.> I thought this falls out
of character type?
Top of p.39 of the report. I don't know what you mean by "falls out", except
perhaps that with the issues divided up, there are some combinations of votes
that only a lunatic would vote. True.
<Miscellaneous other and editorial changes> not sure what they are...
Pages 15 through 44 of the report, except for the 20% or so of that material
covered by explicit ballot items. I'm not sure what they are either.
Your bundlings of issues seem okay to me, although I suspect that if someone
wrote them up properly, they would discover that some of them had been
bundled too tightly and needed to be split. For instance, putting the
removal or deprecation of CHAR-INT and INT-CHAR into CHAR-FONT-UNUSED
doesn't entirely make sense. The others seem good.
If CHAR-FONT-UNUSED fails, or if people only wanted to eliminate CHAR-FONT and not
CHAR-BITS, most of the rest of the proposals get more complicated.
If that's really true, there is something wrong, as it must mean that
the other proposals wouldn't work in the face of implementation-defined
character attributes.
∂26-Jan-89 1926 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu SUMMER MEETING FOR YOUNG SCIENTISTS
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 89 19:26:38 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA22392; Thu, 26 Jan 89 19:25:51 -0800
Message-Id: <8901270325.AA22392@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Thu, 26 Jan 89 19:25:00 PST
Received: by BYUADMIN (Mailer R2.01A) id 3317; Thu, 26 Jan 89 20:23:26 MST
Date: Thu, 26 Jan 89 21:10:25 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
lescanne%CARTAN.CRIN.FR@Forsythe.Stanford.EDU
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: lescanne%CARTAN.CRIN.FR@Forsythe.Stanford.EDU
Subject: SUMMER MEETING FOR YOUNG SCIENTISTS
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
INTERNATIONAL SUMMER MEETING FOR YOUNG SCIENTISTS
ALGEBRAIC AND LOGIC PROGRAMMING
Dresden University of Technology, Department of Mathematics intends to
organize a meeting for young scientists on Algebraic and logic
Programming. The notion of a young scientist ought to be understood
liberally (students and Ph.D. students, e.g.) The meeting is planned
to take place in Dresden
September 4-8 1989
and will be organized by Peter Bachmann and Michael Beetz.
The scientific program of the five days will contain the following issues:
Invited lecturers will give tutorials on the following topics:
Algebraic foundations, term rewriting techniques or logic programming
and its implementation.
The main aim is the informal discussion. Therefore, each participant
is asked to give a short presentation of his current field of
research. Complete results are not always expected for these talks.
To realize low costs (about 50 DM without meal) it is planned to
accommodate the participants in a student hotel. Please return the
application form for taking part by
March 3, 1989
Peter Bachmann Michael Beetz
------------------- cut here ------------------------------------------
Peter Bachmann, Michael Beetz
International Summer Meeting
Dresden University of Technology
Department of Mathematics
Mommenstrasse 13
8027 DRESDEN
German Democratic Republic
Application form
In order to take part in the summer meeting, please, fill in this form
and mail it to above address by March 3, 1989. Please use capitals or
typewriter.
I WISH TO PARTICIPATE IN THE SUMMER MEETING.
Personal details:
Name: __________________________________ _____________________
family name maiden name
__________________________________ male [] / female []
given name
Academic degree: ________________________________________________
College/Institute: ______________________________________________
Telephone/Telex: _______________________________________________
Title of contribution (if already known): ________________________
_________________________________________________________________
_________________________________________________________________
For visa applications:
Date of birth: __________________________________________________
Place of birth: _________________________________________________
Home address : __________________________________________________
____________________________________________________________
Citizenship: ____________________________________________________
Passport Number: _____________________ Issued by: ______________
Border crossing point (if known): ______________________________
Duration of the stay in the GDR from ________ to ________________
___________________ _____________________
date signature
tel. (3751) 46 35 355 Telex 2278z teuni dd
∂26-Jan-89 1928 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu bibliography on semantics of inheritance
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 89 19:28:34 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA22426; Thu, 26 Jan 89 19:27:47 -0800
Message-Id: <8901270327.AA22426@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Thu, 26 Jan 89 19:26:55 PST
Received: by BYUADMIN (Mailer R2.01A) id 3391; Thu, 26 Jan 89 20:24:07 MST
Date: Thu, 26 Jan 89 21:13:20 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Diptendu Dutta <dutta%SKORPIO.USASK.CA@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Diptendu Dutta <dutta%SKORPIO.USASK.CA@Forsythe.Stanford.EDU>
Subject: bibliography on semantics of inheritance
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
In connection with my research work I made up this list. With the
recent interest in OOP and inheritance, I hope there would be more
interest in this area. All the papers referred to in the bibliography are
not hard-core "semantics" papers. I included some relevant papers
which are more general.
Please post about other references in this subject which are known to
you.
------------------------------------------------------------------------
Bibliography on Semantics of Inheritance
----------------------------------------
1. [Ait-Kaci 84] Hassan Ait-Kaci. A Lattice Theoretic Approach to
Computation Based On A Calculus of Partially Ordered Type Structures.
Ph.D dissertation, Computer & Information Sciences Dept., Univ. of
Pennsylvania. 1984.
2. [Albano 83] Antonio Albano. Type Hierarchies & Semantic Data
Models. Sigplan Notices, vol. 18, no. 6, pp 178-186,June 1983.
3. [Bruce & Wegner 86] Kim B. Bruce & Peter Wegner. An Algebraic Model
of Subtypes In Object Oriented Languages. Sigplan Notices, vol. 21,
no. 10, October 1986.
4. [Bruce & Longo 88] Kim B. Bruce & Giuseppe Longo. A Modest Model of
Records, Inheritance & Bounded Quantification. Proceedings of the 3rd
Logic in Computer Science conf. 1988.
5. [Cardelli 84] Luca Cardelli. A Semantics of Multiple Inheritance.
In LNCS #173, Semantics of Data Types. Springer-Verlag. 1984.
6. [Cardelli 88] Luca Cardelli. Structural Subtyping and the notion of
Power Types. In POPL 88.
7. [Cardelli & Wegner 85] L. Cardelli & P. Wegner. On Understanding
Types, Data Abstraction, and Polymorphism. Computing Surveys, vol. 17,
no. 4, Dec. 1985.
8. [Cook 87] W.R.Cook. A Denotational Semantics of Inheritance
(extended abstract). Brown University. Dept. of CS. July 1987.
9. [Danforth & Tomlinson 88] Scott Danforth & Chris Tomlinson. Type
Theories and Object Oriented Programming. Computing Surveys, vol. 20,
no. 1, March 1988.
10. [Dugerdil 86] P. Dugerdil. The Filtering Process: A Mechanism for
Modelling Inheritance in Object Oriented Languages. Advantages In
Artificial Intelligence. Kogan Page Ltd. 1987.
11. [Goguen & Meseguer 88] Joseph A. Goguen & Jose Meseguer. Ordered
Sorted Algebras I: Equational Deduction for Multiple Inheritance,
Polymorphism & Partial Operation. SRI International. 1988.
12. [Kamin 88] Samuel Kamin. Inheritance in Smalltalk80: A
Denotational Definition. POPL 88.
13. [Liskov 87] Barbara Liskov. Data Abstraction & Hierarchy.
OOPSLA87.
14. [Martini 88] Simone Martini. Bounded Quantifiers Have Interval
Models. ACM conf. on Lisp & FP. 1988.
15. [Reddy 87] U. Reddy. On The Semantics Of Object Oriented Languages
(manuscript). Univ. of Illinois. May 1987.
16. [Reynolds 80] John C. Reynolds. Using Category Theory to Design
Implicit Conversions and Generic Operators. LNCS #94,
Semantics-Directed Compiler Generation. Springer-Verlag. 1980.
17. [Toureztky 86] D. Toureztky. The Semantics of Inheritance Systems.
Morgan-Kaufman. 1986.
18. [Wegner 87] Peter Wegner. The Object Oriented Classification
Paradigm. In Research Directions in Object Oriented Programming,
edited by Bruce Shriver & Peter Wegner. Prentice Hall. 1987.
19. [Wolczko 87] M. Wolczko. Semantics of Smalltalk-80. European Conf.
on OO Prgramming. Paris. June 1987.
20. [Zamulin 87] A. V. Zamulin. Relation Between Data Types.
Programmirovanie, no. 4, July-Aug, 1987.
-----------------------------------------------------------------
Diptendu Dutta
Dept of Computational Science
Univ. of Saskatchewan
Saskatoon S7N 0W0 Canada
email adress: dutta@skorpio.usask.ca
∂26-Jan-89 2139 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu PODS 89 - advanced program
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 89 21:39:11 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA26005; Thu, 26 Jan 89 21:38:10 -0800
Message-Id: <8901270538.AA26005@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Thu, 26 Jan 89 21:37:18 PST
Received: by BYUADMIN (Mailer R2.01A) id 3831; Thu, 26 Jan 89 22:33:21 MST
Date: Thu, 26 Jan 89 23:15:15 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
imielins@MARCIN.RUTGERS.EDU
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: imielins@MARCIN.RUTGERS.EDU
Subject: PODS 89 - advanced program
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Eighth ACM SIGACT-SIGMOD-SIGART Symposium
on
PRINCIPLES OF DATABASE SYSTEMS
Philadelphia, Pennsylvania, March 29-31, 1989
INFORMATION
LOCATION
The 8th ACM Symposium on Principles of Database Systems will be held
at The Warwick, a four star hotel, situated in the heart of downtown
Philadelphia, within walking distance from first class restaurants,
concert halls, theaters and galleries. The Warwick Hotel,
a Historical Landmark, combines 19th-century atmosphere with
20th-century amenities.
Checkout and checkin time is noon;
A block of rooms has been reserved until March 6th, 1989.
Please reserve a room by using the form provided or by calling 800-523-4210
Room rates and availability are not guaranteed past March 6th.
REGISTRATION
Advanced registration is requested using the form provided.
Registration rates go up markedly after March 6th. A registration
desk will be open Tuesday night from 7:30pm to 10:00pm, and during the
day on Wednesday (8:30 am to 4:30 pm). Registrants, other than
students, receive admission to the technical sessions, one copy of the
proceedings, reception, lunch, and a banquet at the historical
Franklin Institute.
Student registration, available to full-time students only, includes
the technical sessions, reception and one copy of the proceedings.
Additional copies of the proceedings will be available for sale at
the registration desk.
TRANSPORTATION
There are two choices for ground transportation from the airport to the hotel.
The limousine service from the airport to major Philadelphia hotels including
Warwick is available for about 6 dollars/person. Additionally, taxi fare
to the hotel is about 25 dollars.
For participants driving to The Warwick, parking is available at
the rate 8.50/day at Penn Warwick lot on Chancellor and 17th street.
5 dollar/day rebate is provided for those participants who stay in the hotel.
CLIMATE
Normal daily temperatures in Philadelphia
in March range from 35 to 50 degrees F.
Occasional cold fronts bring northerly winds but snow is rare
at this time of the year.
EVENT LOCATION
All technical sessions, reception, lunch, and business meeting will be held
at The Warwick Hotel. On Thursday night there will be a reception
and banquet at the historical Franklin institute at 20th & the Parkway,
walking distance from the hotel.
TECHNICAL PROGRAM
TUESDAY, MARCH 28, 1989
Reception: 7:30 pm - 10:00 pm, Crystal Room
WEDNESDAY, MARCH 29, 1989
Note: All talks will take place in the Ballroom
TUTORIAL 1: 8:15 am - 9:15 am
Non-monotonic Reasoning,
Teodor C. Przymusinski (University of Texas at El Paso)
SESSION 1: 9:30 am - 10:40 am
Chair: Tomasz Imielinski (Rutgers University)
The Alternating Fixpoint of Logic Programs with Negation
Allen Van Gelder (University of California, Santa Cruz)
Every Logic Program has a Natural Stratification and an Iterated Fixed
Point Model, Teodor C. Przymusinski (University of Texas at El Paso)
A Procedural Semantics for Well Founded Negation in Logic Programs,
Kenneth A. Ross (Stanford University)
Coffee Break: 10:40 am - 11:15 am
SESSION 2: 11:15 am - 12:45 pm
Chair: Teodor C. Przymusinski (University of Texas at El Paso)
Logic Programming as Constructivism: A Formalization and its Application
to Databases, Francois Bry (ECRC, Munich)
Complexity of Query Processing in Databases with OR-Objects,
T. Imielinski and K. Vadaparty (Rutgers University)
A Sound and Complete Query Evaluation Algorithm for Relational Databases
with Disjunctive Information, Li Yan Yuan and Ding-An Chiang (University
of Alberta)
Horn Tables - An Efficient Tool for Handling Incomplete Information in
Databases, Gosta Grahne (University of Helsinki)
Lunch: 12:45 pm - 2:15 pm
SESSION 3: 2:15 pm - 3:45 pm
Chair: Carlo Zaniolo (MCC)
Invited Talk: Automata Theory for Database Theoreticians,
Moshe Y. Vardi (IBM Almaden Research Center)
Declarative Expression of Deductive Database Updates,
Sanjay Manchanda (University of Arizona)
Updating Databases in the Weak Instance Model,
Paolo Atzeni (Universita di Napoli and IASI-CNR) and Riccardo Torlone
(IASI-CNR)
Coffee Break: 3:45 pm - 4:15 pm
SESSION 4: 4:15 pm - 5:45 pm
Chair: Daniel J. Rosenkrantz (SUNY at Albany)
Attribute Agreement,
Y. C. Tay (National University of Singapore)
Can Constant-time-maintainability be More Practical?
Ke Wang (Chongqing University, PRC)
Practical Algorithms for Finding Prime Attributes and Testing Normal Forms,
Heikki Mannila (University of Helsinki) and Kari-Jouko Raiha (Univeristy
of Tampere)
A Decision Procedure for Conjunctive Query Disjointness,
Charles Elkan (Cornell University)
Business Meeting: 8:30 pm - 10:00 pm,
THURSDAY, MARCH 30, 1989
TUTORIAL 2: 8:15 am - 9:15 am
Recursive Query Processing,
Catriel Beeri (Hebrew University)
SESSION 5: 9:30 am - 10:40 am
Chair: Catriel Beeri (Hebrew University)
Bottom-up Beats Top-down for Datalog,
Jeffrey D. Ullman (Stanford University)
On the Power of Alexander Templates,
Hirohisa Seki (Institute for New Generation Computer Technology, Tokyo)
Safety of Datalog Queries over Infinite Databases,
Yehoshua Sagiv (Hebrew University) and Moshe Y. Vardi
(IBM Almaden Research Center)
Coffee Break: 10:40 am - 11:15 am
SESSION 6: 11:15 am - 12:45 pm
Chair: Michael Kifer (SUNY at Stony Brook)
Proof-tree Transformation Theorems and Their Applications,
Raghu Ramakrishnan (University of Wisconsin), Yehoshua Sagi
(Hebrew University), Jeffrey D. Ullman (Stanford University), and
Moshe Y. Vardi (IBM Almaden Research Center)
Linearising Nonlinear Recursions in Polynomial Time,
Yatin P. Saraiya (Stanford University)
Inference of Monotonicity Constraints in Datalog Programs,
Alexander Brodsky and Yehoshua Sagiv (Hebrew University)
Why a Single Parallelization Strategy is Not Enough in Knowledge Bases,
Simona Cohen and Ouri Wolfson (Technion)
Lunch: 12:45 pm - 2:15 pm
SESSION 7: 2:15 pm - 3:45 pm
Chair: William E. Weihl (MIT)
Invited Talk: Modular Architectures for Distributed and Database Systems,
Alfred Z. Spector (Carnegie-Mellon University)
Clustered Multiattribute Hash Files,
Doron Rotem (University of California, Berkeley)
Utilization of B-trees with Inserts, Deletes and Modifies,
Theodore Johnson and Dennis Shasha (New York University)
Coffee Break: 3:45 pm - 4:15 pm
SESSION 8: 4:15 pm - 5:30 pm
Chair: Hector Garcia-Molina (Princeton University)
Fractals for Secondary Key Retrieval,
Christos Faloutsos and Shari Roseman (University of Maryland, College Park)
Declustering Using Error Correcting Codes,
Christos Faloutsos and Dimitrios Metaxas (University of Maryland, College Park)
The Impact of Recovery on Concurrency Control,
William E. Weihl (MIT)
Concurrency Control for Nested Transactions Accessing B-trees,
Ada Fu and Tiko Kameda (Simon Fraser University)
Reception and Banquet at Franklin Institute, 6-10 pm.
FRIDAY, MARCH 31, 1989
TUTORIAL 3: 8:15-9:15
Expressive Power of Query Languages,
Victor Vianu (University of California, San Diego)
SESSION 9: 9:30 am - 10:40 am
Chair: Victor Vianu (University of California, San Diego)
Hypothetical Datalog with Stratification: Complexity and Expressibility,
Anthony J. Bonner (Rutgers University)
Inductive Pebble Games and the Expressive Power of Datalog,
V. S. Lakshmanan and A. O. Mendelzon (University of Toronto)
On the First-Order Expressibility of Recursive Queries,
Stavros S. Cosmadakis (IBM T.J. Watson Research Center)
Coffee Break: 10:40 am - 11:15 am
SESSION 10: 11:15 am - 12:45 pm
Chair: Ashok K. Chandra (IBM T.J. Watson Research Center)
Expressibility of Bounded-Arity Fixed-Point Query Hierarchies,
Pratul Dublish and S. N. Maheshwari (IIT Delhi)
Relational Database Behavior: Utilizing Relational Discrete Event Systems
and Models, Zvi M. Kedem and Alexander Tuzhilin (New York University)
Untyped Sets, Invention, and Computable Queries,
Richard Hull and Jianwen Su (University of Southern California)
Lunch: 12:45 pm - 2:15 pm
SESSION 11: 2:15 pm - 3:45 pm
Chair: Oded Shmueli (Technion)
Modeling Complex Structures in Object-Oriented Databases,
C. Lecluse and P. Richard (GIP Altair)
C-Logic of Complex Objects,
Weidong Chen and David S. Warren (SUNY at Stony Brook)
A Logic for Object-Oriented Logic Programming (Maier's O-Logic: Revisited),
Michael Kifer and James Wu (SUNY at Stony Brook)
Type Systems for Querying Class Hierarchies with Non-Strict Inheritance,
Alexander Borgida (Rutgers University)
-------------------------------------------------------------------------------
CONFERENCE ORGANIZATION
Sponsors: SIGACT, SIGMOD, and SIGART
Executive Committee: Ashok K. Chandra, Seymour Ginsburg,
Tomasz Imielinski, Avi Silberschatz,
Moshe Y. Vardi, Mihalis Yannakakis
Conference Chair: Avi Silberschatz, Dept. of Computer Sciences,
University of Texas at Austin, Austin, Texas 78712.
(512) 471-9706, avi@cs.utexas.edu
Program Chair: Ashok K. Chandra, IBM T.J. Watson Research Center
P.O. Box 218, Yorktown Heights, NY 10598.
(914) 945-1752, ashok@ibm.com (bitnet ASHOK@YKTVMV)
Local Arrangements Chair: Tomasz Imielinski, Dept. of Computer Science,
Rutgers University, New Brunswick, NJ 08903.
(201) 932-3551, imielinski@aramis.rutgers.edu
Program Committee: Catriel Beeri, Ashok K. Chandra, Hector Garcia-Molina,
Michael Kifer, Teodor C. Przymusinski, Daniel J. Rosenkrantz, Oded Shmueli,
Victor Vianu, William E. Weihl, Carlo Zaniolo.
ADVANCE REGISTRATION FORM, ACM-PODS
Please send this form or a facsimile along with a money order or check
(payable to 8th ACM SYMPOSIUM ON PRINCIPLES OF DATABASE SYSTEMS) to:
ACM-PODS Registration
c/o Carol Petty
Dept. of Computer Science
Rutgers University
New Brunswick, NJ 08903
(Before Mar. 6) (After)
ACM and SIG member $220 $285
ACM member only $230 $295
SIG member only $235 $300
Nonmember $285 $350
Student $ 50 $ 60
Requests for refunds will be honored until March 6, 1989.
Name_____________________________________________________________
Affiliation_________________________________________________________
City_____________________________State________________Zip__________
Country_____________________________Telephone______________________
Net Address________________________________________________________
_____ Check here if confirmation of registration is required.
Dietary restrictions: _______Kosher _______Vegetarian
HOTEL RESERVATION FORM, ACM-PODS March 1989
Please mail this form or a facsimile (being sure to mention the ACM-PODS
Conference) by March 6 to:
The Warwick Hotel,
17th at Locust Street
Philadelphia, PA 19103
Tel: (215) 735-6000
or (800) 523-4210
Accomodations desired:
_____Single $80
_____Double $90
Arrival date_____________________________________Time__________________________
Departure date___________________________________Time__________________________
Name_________________________________________________________________________
Sharing room with______________________________________________________________
Address________________________________________________________________________
City_______________________________State__________________Zip__________________
Country________________________________________________________________________
All rooms will be held until 4pm the day of arrival without deposit/guarantee.
For arrivals later than 4pm please guarantee to a major credit card:
_____Amer. Express _____VISA _____Mastercard _____Diners _____Discover
Credit Card number____________________________________________________________
Exp. Date___________________________________________________________________
Signature____________________________________________________________________
∂26-Jan-89 2300 @polya.Stanford.EDU:tah@linz MTC Seminar
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 89 23:00:49 PST
Received: from linz.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA27812; Thu, 26 Jan 89 22:59:21 -0800
Received: by linz.stanford.edu (5.59/25-eef) id AA27752; Thu, 26 Jan 89 22:53:13 PDT
Message-Id: <8901270653.AA27752@linz.stanford.edu>
To: lop@polya
Subject: MTC Seminar
Reply-To: tah@cs.stanford.edu
Date: 26 Jan 89 22:53:11 PST (Thu)
From: Tom Henzinger <tah@linz>
Jan. 27, MJH 301:
Martin Rinard will talk about Kahn semantics for dataflow networks,
the Brock-Ackerman anomaly, and fully abstract trace models (from
the paper of B. Jonsson at POPL 89).
We'll start a bit late, at 12:10.
∂27-Jan-89 0307 X3J13-mailer Issues DECLARATION-SCOPE and DEFINING-MACROS-NON-TOP-LEVEL
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 27 Jan 89 03:07:49 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA13678g; Fri, 27 Jan 89 03:02:12 PST
Received: by bhopal id AA17641g; Fri, 27 Jan 89 03:04:33 PST
Date: Fri, 27 Jan 89 03:04:33 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901271104.AA17641@bhopal>
To: barmar@Think.COM
Cc: Moon@stony-brook.scrc.symbolics.com, sandra%defun@cs.utah.edu,
X3J13@sail.stanford.edu
In-Reply-To: Barry Margolin's message of Wed, 25 Jan 89 12:32 EST <19890125173236.0.BARMAR@OCCAM.THINK.COM>
Subject: Issues DECLARATION-SCOPE and DEFINING-MACROS-NON-TOP-LEVEL
re: I think JonL meant that toplevel implies null lexical environment, not
the other way around.
You're quite right. The context of the two examples I gave was to make
very clear that LOCALLY implies a non-null lexical environment, and that
you can't simply "fake it" at toplevel. As Bacher points out, it is
rather unsettling to have "toplevel" pass through this construct with
lexical appendages, but be blocked by the straightforward EVAL-WHEN.
[However, it's not clear to me whether Walters original suggestion really
did have the implication that moon inferred. I found Rob MacLaughlin's
"early-eval/late-eval" semantics for compilation processing a bit hard
to follow; but it's entirely possible that he *would* have processed
the defmacro in moon's oddp example.]
Still waiting for someone to suggest that the term "toplevel" be
abandoned for this purpose, and some more agressive term taken on.
-- JonL --
∂27-Jan-89 0825 @Score.Stanford.EDU:chandler@polya.Stanford.EDU 1/31 Faculty Lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Jan 89 08:25:35 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 27 Jan 89 08:21:48-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA09219; Fri, 27 Jan 89 08:22:53 -0800
Date: Fri, 27 Jan 1989 8:22:51 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, bureaucrats@score
Cc: linvill@sierra, reis@sierra
Subject: 1/31 Faculty Lunch
Message-Id: <CMM.0.87.601921372.chandler@polya.stanford.edu>
This is to remind you of next week's faculty lunch...12/15 in Margaret Jacks
Hall, room 146. John Linvill and Rick Reis will be our guests and will
discuss the CIS mentor program. Don't forget to mark your calendars!
∂27-Jan-89 0833 @Score.Stanford.EDU:tom@polya.Stanford.EDU NCUBE
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Jan 89 08:33:28 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 27 Jan 89 08:24:14-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA09293; Fri, 27 Jan 89 08:25:18 -0800
Date: Fri, 27 Jan 89 08:25:18 -0800
From: Tom Dienstbier <tom@polya.Stanford.EDU>
Message-Id: <8901271625.AA09293@polya.Stanford.EDU>
To: csd@polya.Stanford.EDU, su-computers@score, faculty@polya.Stanford.EDU
Subject: NCUBE
Once again the people from NCUBE have asked me if someone may be interested
in using the NCUBE, located in the Department of Computer Science machine
room. The configuration is 64 processors, basically very little memory,
small disk, and tape drive. NCUBE would like to be responsive to research
that could be done on the system, specially if it would be of interest to
NCUBE. My feeling is, the system is pretty archaic to be used sensibly
in the state that it is in. To be usuful, upgraded processors, much
larger cache/memory, software, and ethernet connectivity would be
needed/required.
All this is very expensive and if NCUBE doesn't come through to help out,
it won't make much sense.
Please contact me if you are interested in using this machine or for more
information. I might add that the NCUBE is not currently operated/maintained
by anyone. So whomever may want to use this machine assumes this
responsibility.
I(CSDCF) am a contact with NCUBE for the simple reason that it sits in
my machine room.
The NCUBE folks will be getting back to me early next week. So if there is
interest let me know soon.
If there is not any interest I suspect that it will soon disappear.
Tom Dienstbier
CSDCF
∂27-Jan-89 0918 @Score.Stanford.EDU:tom@polya.Stanford.EDU alto's/dovers
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Jan 89 09:18:17 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 27 Jan 89 09:12:58-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA10887; Fri, 27 Jan 89 09:14:04 -0800
Date: Fri, 27 Jan 89 09:14:04 -0800
From: Tom Dienstbier <tom@polya.Stanford.EDU>
Message-Id: <8901271714.AA10887@polya.Stanford.EDU>
To: csd@polya.Stanford.EDU, su-computers@polya.Stanford.EDU,
faculty@polya.Stanford.EDU
Subject: alto's/dovers
I am in the process of disposing the Alto's and DOVER printers.
In the past there has been some interest by some of you for this equipment.
If you are still interested please contact me.
Tom Dienstbier
415-723-1767
∂27-Jan-89 1041 @Score.Stanford.EDU:goldberg@Jinn.stanford.edu Potential visitor
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Jan 89 10:41:15 PST
Received: from Jinn.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 27 Jan 89 10:37:39-PST
Received: by Jinn.stanford.edu (4.0/25-eef) id AA16573; Fri, 27 Jan 89 10:38:35 PST
Date: Fri, 27 Jan 89 10:38:35 PST
From: Andrew Goldberg <goldberg@Jinn.stanford.edu>
Message-Id: <8901271838.AA16573@Jinn.stanford.edu>
To: faculty@score
Subject: Potential visitor
Prof. Mei-rui Xu, Director of the Institute of Information Science
of Beijing University, has applied for a visiting position for the
next year. He has his own support.
Prof. Xu's interests are in VLSI algorithms, computation complexity,
and formal languages.
Is anybody interested in having him as a visitor next year?
I think we should not invite anybody without a faculty "sponsor",
especially since we have many strong candidates and very little space.
Prof. Hu's vitae is available from Rosemary Napier, MJH 340.
--Andy
∂27-Jan-89 1101 @Score.Stanford.EDU:goldberg@Jinn.stanford.edu Industrial Lecturer
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Jan 89 11:00:57 PST
Received: from Jinn.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 27 Jan 89 10:57:36-PST
Received: by Jinn.stanford.edu (4.0/25-eef) id AA16489; Fri, 27 Jan 89 09:07:39 PST
Date: Fri, 27 Jan 89 09:07:39 PST
From: Andrew Goldberg <goldberg@Jinn.stanford.edu>
Message-Id: <8901271707.AA16489@Jinn.stanford.edu>
To: faculty@score
Subject: Industrial Lecturer
Gio suggested to me that Litwin, who was supposed to teach 309C
as an Industrial Lecturer this spring but cannot make it, may
be able to teach a course next fall. If there are no objections,
I will try to arrange this.
--Andy
∂27-Jan-89 1329 @Score.Stanford.EDU,@polya.Stanford.EDU:hayes@arisia.xerox.com NCUBE
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Jan 89 13:28:58 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 27 Jan 89 13:25:37-PST
Received: from arisia.Xerox.COM by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA28069; Fri, 27 Jan 89 13:26:36 -0800
Received: by arisia.Xerox.COM
(5.59++/IDA-1.2.6) id AA24059; Fri, 27 Jan 89 13:25:12 PST
Date: Fri, 27 Jan 89 13:25:12 PST
From: Pat Hayes <hayes@arisia.xerox.com>
Message-Id: <8901272125.AA24059@arisia.Xerox.COM>
To: csd@polya.Stanford.EDU, su-computers@score.ARPA,
faculty@polya.Stanford.EDU
In-Reply-To: Tom Dienstbier's message of Fri, 27 Jan 89 08:25:18 -0800 <8901271625.AA09293@polya.Stanford.EDU>
Subject: NCUBE
I too have this thing which people might like to use, I guess. You
dont need to know anything about it in detail. Its pretty oldfashioned
and needs a lot of work to make it into something which is more than a
bad joke. Whats more, people using it can only be a damn nuisance to
me. But if thats what you want, then let me know. Sigh. Oh, by the
way, if it breaks, its YOUR FAULT. If you still want it, let me have a
written proposal in the next two days.
Pat
∂29-Jan-89 1101 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu CIS Mentor program
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Jan 89 11:01:54 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Sun 29 Jan 89 10:58:44-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA02236; Sun, 29 Jan 89 10:58:52 PDT
Date: Sun, 29 Jan 89 10:58:52 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8901291858.AA02236@Tenaya.stanford.edu>
To: faculty@score
Subject: CIS Mentor program
The CIS has worked out an excellent arrangement with their member
companies that associates graduate students with companies and
provides PhD research assistantships in the process. This program
will undoubtedly be of interest to many faculty in CS. It will be
explained at our faculty lunch this coming Tuesday, January 31, by
Rick Reis and John Linvill. 12:15, MJH 146.
[For future planning: The 2/7 faculty lunch will discuss the
proposed "tax" on gifts with guests Bienenstock, Byer, and Devaney.
The 2/14 faculty lunch will continue discussion of the PhD program.
The next three after that our still open; suggestions welcome.]
-Nils
∂29-Jan-89 1251 hoffman@csli.Stanford.EDU The Symbolic Systems Forum Feb. 3rd
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Jan 89 12:51:44 PST
Received: by csli.Stanford.EDU (4.0/inc-1.0)
id AA00278; Sun, 29 Jan 89 12:20:50 PST
Date: Sun 29 Jan 89 12:20:50-PST
From: Reid Hoffman <HOFFMAN@CSLI.Stanford.EDU>
Subject: The Symbolic Systems Forum Feb. 3rd
To: TheForum@csli.Stanford.EDU
Message-Id: <602108450.0.HOFFMAN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
This week's Symbolic Systems Forum will be
Structure Yes, Symbols No
a talk by
Professor Jerome A. Feldman
Institute for Cognitive Science,
Berkeley, CA
Abstract:
Computer Science, Artificial Intelligence and many related fields have
followed symbol-processing paradigms almost without exception. Recent
work has suggested alternative views of intelligent activity based on
connectionist (or PDP or `neural') networks. This talk will discuss a
``Structured" connectionist approach which attempts to capture the
best features of symbollic and neural-style computation. After some
preliminaries, the talk will focus on a connectionist model of visual
recognition which is claimed to be (the only model) consistent with
the relevant biological, behavioral and computational findings.
Finally, we will try to indicate what this model suggests about how
intelligence as realized is animals and artifacts.
Time: Friday, Feb. 3rd, 3:15
Place: Building 60, Room 60-61G
The talk will be open to the general public. To join the mailing list,
send mail to hoffman@csli
Next week: Professor Bernardo Huberman (Xerox PARC, Physics) will speak on
"The Ecology of Computation"
-------
∂29-Jan-89 1433 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU Protesting the censorship of a newsgroup
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Jan 89 14:33:07 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sun 29 Jan 89 14:29:38-PST
Message-ID: <vhr$U@SAIL.Stanford.EDU>
Date: 29 Jan 89 1431 PST
From: John McCarthy <JMC@SAIL.Stanford.EDU>
Subject: Protesting the censorship of a newsgroup
To: faculty@SCORE.Stanford.EDU
Recently AIR and SDC have censored the newsgroup rec.humor.funny.
This has resulted in about 40 messages in su-etc objecting to the
purge and no messages in its favor. There follows a draft
statement on the issue. Individual "signatures" will be
solicited for a final version.
rec.humor.funny is still available on Polya and other computers
not under the control of AIR and SDC. It has been added to
gang-of-four. The following messages include Ralph Gorin's purge
memo, a general exposition of the situation including
recommendations.
I hope the Department will eventually make an explicit
decision not to censor csd-cf and publicize the decision.
∂29-Jan-89 1436 @Score.Stanford.EDU:Mailer@SAIL.Stanford.EDU rec.humor.funny
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Jan 89 14:36:22 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sun 29 Jan 89 14:31:24-PST
Message-ID: <LhraH@SAIL.Stanford.EDU>
Date: 29 Jan 89 1431 PST
From: John McCarthy <JMC@SAIL.Stanford.EDU>
Subject: rec.humor.funny
To: su-etc@SAIL.Stanford.EDU, faculty@SCORE.Stanford.EDU
Statement of protest about the AIR purge of rec.humor.funny.
Computer scientists and computer users have been involved in
making information resources widely available since the 1960s.
Such resources are analogous to libraries. The newsgroups are
available on various networks are the computer analog of
magazines and partial prototypes of future universal computer
libraries. These libraries will make available the information
resources of the whole world to anyone's terminal or personal
computer.
Therefore, the criteria for including newsgroups in computer
systems or removing them should be identical to those for
including books in or removing books from libraries. For this
reason, and since the resource requirements for keeping
newsgroups available are very small, we consider it contrary to
the function of a university to censor the presence of newsgroups in
University computers. We regard it as analogous to removing a
book from the library. To be able to read anything subject only
to cost limitations is an essential part of academic freedom.
We therefore think that AIR and SDC should rescind the purge of
rec.humor.funny.
∂29-Jan-89 1449 @Score.Stanford.EDU:Mailer@SAIL.Stanford.EDU Censoring rec.humor.funny
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Jan 89 14:49:22 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sun 29 Jan 89 14:46:23-PST
Message-ID: <Lhrmo@SAIL.Stanford.EDU>
Date: 29 Jan 89 1445 PST
From: John McCarthy <JMC@SAIL.Stanford.EDU>
Subject: Censoring rec.humor.funny
To: su-etc@SAIL.Stanford.EDU, faculty@SCORE.Stanford.EDU
This is an explanation for people not familiar with newsgroups.
To understand the issue, you have to know something
about network newsgroups.
1. There are about 500 national ``newsgroups'' coming
into the Computer Science Department's VAX computer named Polya.
You may think of them as magazines to which the library aspect of
Polya subscribes, but they are all free. Many Stanford computers
receive about the same list.
2. A user of one of these computers can give the command
rn, and the computer will show him the first new item in the first
newsgroup to which he personally has ``subscribed''. He can read
items or skip them or move on to the next newgroup. One can spend
a lot of time at this. One can add or remove newsgroups from one's
personal list.
3. One can also send items to a newsgroup by electronic mail.
4. There are two kinds of newsgroups, unmoderated and moderated.
Electronic mail received by the computer program maintaining an
unmoderated newsgroup automatically remails it to all the subscribers.
Moderated newsgroups have human editors that select what will be
included. Both kinds flourish.
5. Because some of the newsgroups are received in batches,
it is doubtful that every newsgroup received on Stanford computers
has been selected by anybody. Maybe some of them are not read
by anybody.
6. The cost of receiving newsgroups is very low. The installation
sets a policy on how long the items are kept, and this is implemented
by a program that usually is automatically activated nightly.
7. The subjects of newsgroups include the following.
a. Technical discussions of various scientific and engineering and
philosophical topics.
b. Political and social controversy.
c. Material of interest to subgroups: feminists, gays, Jews, sex,
drugs.
d. Material concerning users of particular kinds of computer and
particular programming languages.
e. Recipes and jokes.
f. Things for sale. Product announcements.
\noindent THE PRESENT CONTROVERSY
Brad Templeton, who runs a small company in Waterloo, Canada
has operated as a hobby a moderated newsgroup for jokes called
rec.humor.funny. Templeton selects jokes for humorousness and
explicitly abjures ``political correctness'' as a criterion.
Jokes that might be considered offensiveness are encrypted in
the C13 cipher, i.e. letters are displaced by 13 in the alphabet.
If a joke is classified as potentially offensive, the reader
can skip it without decrypting it. Templeton also maintains the
newsgroup rec.humor.d that anyone can use to comment on his selection
policy.
Templeton was attacked by an M.I.T graduate student in civil
engineering. The attack first appeared in some other newsgroups,
and later in the newspapers in Waterloo. The attack was triggered
by the following joke.
A Jew and a Scotsman had dinner in a restaurant. At the end, the
Scotsman was heard to say, ``I'll pay''. The next day there was
a newspaper headline, ``Jewish ventriloquist murdered''.
No Jew to whom I have told this joke was offended, but I haven't
had a chance to try Scots.
According to Templeton, this is a joke he would normally encrypt,
but he forgot that time. His apology for this didn't satisfy his
critic(s).
The upshot in Waterloo was that he no longer distributes rec.humor.funny
through the University of Waterloo computer and the University only
receives G-rated jokes.
\noindent THE STANFORD FLAP
Early in December, a programmer at SDC pointed out the
controversy to John Sacks, apparently just as an item of gossip,
making no suggestion that Stanford do anything to prevent Stanford
people from reading rec.humor.funny.
However, the matter gurgled through the Stanford computer
bureaucracy, the upper reaches of the Stanford Administration and
Stanford legal counsel. The matter was kept confidential among
these officials for no reason that was ever made explicit. Perhaps
it was just habit. After a month and a half, Ralph Gorin, head
of AIR and John Sack, head of SDC, jointly announced that rec.humor.
funny was to be purged from the computers under their control.
Here are some related facts.
1. There are many computers not under their control including
those operated by various research groups in the Engineering School,
the Computer Science Department and the Center for Studies in Language
and Information and the Music Department. None of these other
organizations have taken any action or seem inclined to do so as yet.
rec.humor.funny has been added to the gang-of-four computer operated
by the Qlisp research project.
2. This bit of censorship is a random thrust in the dark.
A few number of other newsgroups are in far worse taste than
rec.humor.funny ever is.
3. The effort to remove rec.humor.funny has taken several
man days of programmer time by people who have no personal taste
for this particular job. It may not have been entirely successful
for technical reasons. The costs are in purging the library---not in
maintaining it.
4. Stanford has a legal right to do what its administration
pleases, just as it has a legal right to purge the library or
fire tenured faculty for their opinions.
\noindent OPINION
Newsgroups are a new communication medium just as printed
books were in the 15th century. I believe they are one step
towards universal access through everyone's computer terminal to
the whole of world literature. AIR and SDC setting up an index
of prohibited newsgroups is in the same tradition as the Pope's
15th century Index Liber Prohibitorum.
Stanford should consider the newsgroups received by its
various computers as analogous to books and magazines in its
library. Costs require a library to be selective in the books
and magazines in its library. Costs don't seem to be a factor
here as long as there are a mere 500 newsgroups.
Stanford should maintain the part of the tradition of academic
freedom in case of newsgroups.
Should Stanford not persist in its foolish decision and even
attempt to enforce it Campus wide, it will acquire somewhat of
a reputation as a boobocracy, but doubtless it will survive this.
One might regard this as another sign of a more general
censorious trend, but maybe it won't get worse.
∂29-Jan-89 1508 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU rec.humor.funny
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Jan 89 15:08:33 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sun 29 Jan 89 15:05:13-PST
Message-ID: <dhrew@SAIL.Stanford.EDU>
Date: 29 Jan 89 1436 PST
From: John McCarthy <JMC@SAIL.Stanford.EDU>
Subject: rec.humor.funny
To: faculty@SCORE.Stanford.EDU
Here is the Gorin and Sack message
To the Stanford community,
In Information Resources, we have been confronted with the existence
of a Usenet (Unix users') bulletin board, rec.humor.funny, that
contains jokes including, among others, jokes based on racial, ethnic,
sexual, religious, and other stereotypes. Jokes based on such
stereotypes perpetuate racism, sexism, and intolerance; they undermine
an important University purpose: our collective search for a better
way, for a truly pluralistic community in which every person is
acknowledged an individual, not a caricature.
We have weighed our love of freedom of expression and the free
exchange of ideas in contrast to our respect for the dignity and
rights of every individual. In this situation we find: this bulletin
board does not serve a University educational purpose; its content is
offensive; it does not, in itself, provide a forum for the examination
and discussion of intolerance, an exchange of views, or the expression
of views of the members of the University community.
Stanford University has no commitment to maintain our computing
facilities as a generalized forum for outsiders' indiscriminate
purposes. We are sensitive to the pain caused by racial, religious,
and sexual affronts. For these reasons, we have decided not to have
that bulletin board file on the computers operated by Information
Resources.
We endorse the continued use of our local, unmoderated computer
bulletin boards by members of the University community for the
discussion of ideas, including those that are unpopular. In such a
forum, ideas are subject to the thoughtful judgement of others.
Ralph Gorin, Director John Sack, Director
Academic Information Resources Stanford Data Center
-------
∂29-Jan-89 1721 @Score.Stanford.EDU:coraki!pratt@Sun.COM rec.humor.funny
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Jan 89 17:21:19 PST
Received: from Sun.COM by SCORE.STANFORD.EDU with TCP; Sun 29 Jan 89 17:18:09-PST
Received: from sun.Sun.COM (sun-bb.sun.com) by Sun.COM (4.1/SMI-4.0)
id AA13400; Sun, 29 Jan 89 17:21:09 PST
Received: from coraki.UUCP by sun.Sun.COM (4.0/SMI-4.0)
id AA20223; Sun, 29 Jan 89 17:18:53 PST
Received: by (4.0/SMI-4.0Beta)
id AA14509; Sun, 29 Jan 89 17:18:31 PST
Date: Sun, 29 Jan 89 17:18:31 PST
From: Vaughan Pratt <coraki!pratt@Sun.COM>
Message-Id: <8901300118.AA14509@>
To: faculty@score.stanford.edu
Subject: rec.humor.funny
Electronic bboards should observe the prevailing limits on propriety
for comparably *accessible* and *protected* media.
Accessibility. The Stanford Daily is at least as accessible as the
most publicly accessible electronic bboard. Would the Daily get off
scot-free, so to speak, if it ran that joke?
Protection. Do AIR and SDC receive all the freedom-of-speech and
freedom-of-press protections accorded the Daily? If not then
appropriately tighter controls may be prudent.
But neither of these factors were mentioned in the official Information
Resources justification. What did appear instead was the following
most disquieting distinction between external and internal sources,
with only the former being subject to censorship of "unpopular" ideas.
We endorse the continued use of our local, unmoderated computer
bulletin boards by members of the University community for the
discussion of ideas, including those that are unpopular.
High time H&S replaced its overly broad Western Culture program
with a more focused Stanford Culture program.
In twenty years time you'll be able to tell if the after-dinner speaker
is a Stanford alumnus by his jokes.
-v
∂29-Jan-89 1804 LOGMTC-mailer Logic seminar
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Jan 89 18:04:39 PST
Received: by csli.Stanford.EDU (4.0/inc-1.0)
id AA05795; Sun, 29 Jan 89 18:02:57 PST
Date: Sun 29 Jan 89 18:02:56-PST
From: Sol Feferman <SF@CSLI.Stanford.EDU>
Subject: Logic seminar
To: logic@csli.Stanford.EDU
Message-Id: <602128976.0.SF@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
Seminar in Logic and Foundations
Speaker: Philip Scowcroft, Mathematics, Stanford
Title: "Introduction to Intuitionistic Mathematics" (second of two lecture{)
Place: Room 381-T, Math Corner Stanford
Time: Tuesday, January 31, 4:15-5:30 PM
* * * *
The speaker for Tuesday, Feb.7 will be Michael Beeson of San Jose State Univ.
The title of his talk will be:
"Applications of Gentzen's proof theory to automated deduction."
This talk will assume some familiarity with Gentzen's sequential systems
G1 and G3 from Kleene's "Introduction to Metamathematics" and Horn clause
logic programming, including the unification algorithm, as presented for
example in Clocksin and Mellish, "Programming in Prolog".
S. Feferman
-------
∂30-Jan-89 0743 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Faculty Lunch: The PhD Program
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 89 07:42:56 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sun 29 Jan 89 23:56:04-PST
Message-ID: <xhE3b@SAIL.Stanford.EDU>
Date: 29 Jan 89 2357 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Faculty Lunch: The PhD Program
To: faculty@SCORE.Stanford.EDU
∂24-Jan-89 1515 @Score.Stanford.EDU:bhayes@polya.Stanford.EDU Faculty Lunch: The PhD Program
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Jan 89 15:12:20 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 24 Jan 89 15:10:30-PST
Received: from LOCALHOST by polya.Stanford.EDU (5.59/25-eef) id AA12360; Tue, 24 Jan 89 15:11:38 PDT
Message-Id: <8901242311.AA12360@polya.Stanford.EDU>
To: csd-bboard@polya.Stanford.EDU, phd-program@polya.Stanford.EDU
Subject: Faculty Lunch: The PhD Program
Date: Tue, 24 Jan 89 15:11:36 -0800
From: bhayes@polya.Stanford.EDU
A real humdinger of a lunch this time, the topic being, of course, The
PhD Program. It was advertised as a flamefest, but many toe-toasters
were disappointed.
Mike Genesereth led off by saying that one of the main concerns of the
PhD committee, which he chairs, is the increasing amount of time it
takes to get a PhD here. The committee is also concerned with the
general student unhappiness. The committee proposed a research
requirement, implimented with some added bureaucracy, to get students
started on the research trail quickly. Neither the bureauracy nor the
requirement were wholeheartedly supported by the faculty. There are a
number of proposals under consideration, including changes to the comp,
but there should be an attempt to keep the discussion on target:
research.
[I can tell, by the way, that this is going to be a long message. I
may add a few pithy remarks at the end, so even if you get bored, I,
as their author expectant, urge you to read them.]
Ed Feigenbaum spoke next. We are a research university, and research
is the soul of this department. When the department was founded, it
was founded with the Carnegie model in mind. Bring students in,
"indoctrinate" them, get them "married" to research projects, more or
less ignore courses. We went half way on this: the courses are taught,
but they aren't required.
Over the years, we've drifted more to courses, and students, paranoid
over the comp, put off their research. Students are admitted not for
their transcripts, not for the GRE scores, but for an elusive spark and
desire to do research. Then the adventure is postponed, and the spark
is snuffed out.
The argument is often made that the field has grown. But at the same
time, the number of abstractions have grown, and so the total which
must be learned has remained fairly constant. We underestimate the
ability of students to learn things on their own when they need to
know. The comp, if testing the leaves of the tree, is wrong. We
should be testing more for the abstractions, and less for the details.
Research advisors should ensure early exciting research. The comp is
too much of a drain on the energy of the students.
Bob Floyd provided the last keynote. We need to turn out people with
large views, not sub-specialists. Some bredth is needed, and we need
to enforce that requirement somehow. An exam provides a certain
objectivity. The comp gives us a chance to deal with mistakes we may
have made at admission time. The bredth requirement should come before
the depth requirement, since the bredth benifits the depth more than
the other way around. But this shouldn't be a time-sink. We should
reexamine the goals of the comp; it's getting wider and deeper. We
should be testing the ability to integrate ideas across areas.
Ed Feigenbaum brought up a few more points. Classes don't teach the
essential: the heuristics of research. How to shape a problem into a
research topic, and fit it in with the work elsewhere. How to cut
through a mass of detail and find the essential track of the problem.
Unless students are really involved, they won't learn this.
Nils asked that we hear from some of the younger faculty how things
worked at their universities, and how Electrical Engineering here
works. A quick summary:
CMU:
The program takes longer, and nobody is happy about the length of time.
They keep restructuring the breadth exam. Currently there are four
exams of three parts each. There is a survey course for each exam
lasting one quarter. The exams have to be passed eventually, but
there's no time limit. If you fail the exams and you're doing
research, you won't get booted. Each exam is three parts, two take
home and one not. It's not a monolithic comp like here, and students
treat it lighter then we treat the comp.
There are two Black Friday meetings each year. They are long, every
student is discussed, and all the faculty go. Quarterly evaluations
are used to establish progress through the system, as well as the exams.
Students are happier there than here. They gripe and moan, but they
wouldn't tell prospective students that they should go elsewhere, as
students here do.
Students are "married" to researchers by a committee after a few weeks
there. Faculty recruit if they want students; they send out senior
students, they hold parties. Students are usually given their first
choice of advisor. The "divorce" rate is about 50%, and divorce is
no-fault.
MIT:
There are seven obstacles. [Hmm. I didn't count then, so I may not
have seven here.] There are four exams, which are roughly four finals
from survey courses. You need to pass the exam, with or without the
course. There's a Master's thesis. There's an oral exam to enter
candidacy. It's not pass/fail, just numerical grade on the exams. You
never take the exam again. One strategy that can work is to ignore the
exams, fail them if you do, and write a good thesis. This can still
pass you into candidacy for the PhD. No course requirements.
Students almost always are in a research group, starting early on.
There's social pressure to get into a group, their are advisors out
pitching for students.
UC Berkeley:
[This got a bit muddled in my notes because time was running short, and
the two UCB grads couldn't agree on what the requirements were. Seems
they've changed quite a bit over the last few years.]
Prelims [like our comps] are offered twice yearly. Students stop their
work for two months to stude for them, and generally pass. Once a
student has done some research, it is presented to the faculty, who
then give feedback to the student.
There's a BIG course requirement, about two years. But professors
don't take courses seriously. In the old days, Berkeley had a 50%
failure rate, with a Master's as the parting gift. Now they admit
separately to the MS and PhD programs.
Well, by now it was getting late, people were bailing out in droves,
and it was Marcia, Ed, and Geoff's turn to speak, as the student reps
on the PhD program committee. Hardly seems fair, does it? Good sense
was abundant, and the discussion will be resumed at a later lunch,
starting with Marcia, Ed, and Geoff.
I've posted this to the phd-program bboard, and hope that if you have
any comments, you'll direct them there. Also, as I said, the three
students from the PhD committee [say it with me...], Marcia, Ed, and
Geoff, will be presenting the student view of things. If you've got
things to say, but don't want to sling it around the bboard, they're
who you should get in touch with.
∂30-Jan-89 0747 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Spokespersons meeting of Jan. 23, 1989
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 89 07:47:23 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sun 29 Jan 89 23:56:17-PST
Message-ID: <xhE40@SAIL.Stanford.EDU>
Date: 29 Jan 89 2357 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Spokespersons meeting of Jan. 23, 1989
To: faculty@SCORE.Stanford.EDU
∂25-Jan-89 1141 @Score.Stanford.EDU:kos@polya.Stanford.EDU Spokespersons meeting of Jan. 23, 1989
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Jan 89 11:41:38 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 25 Jan 89 11:39:47-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA25829; Wed, 25 Jan 89 11:25:18 PDT
Date: Wed, 25 Jan 1989 11:25:15 PST
Sender: Andrew Kosoresow <kos@polya.stanford.edu>
From: Andrew P. Kosoresow <kos@polya.stanford.edu>
To: csd@score
Cc: bureaucrats@polya.Stanford.EDU
Subject: Spokespersons meeting of Jan. 23, 1989
Message-Id: <CMM.0.87.601759515.kos@polya.stanford.edu>
From the spokespersons meeting of January 29, 1988:
o As space is getting tighter at Jacks, various alternatives were discussed
including renting more space at Welch Road or staying at Tresidder for
longer than previously anticipated. The Space Committee will be looking
into these and other alternatives.
o The format and existence of the CSD Colloquiums was discussed. Due to the
low attendance at last Tuesday's colloquium, several ways of bolstering
attendance were suggested. There is a possibility of making it into a
distinguished speaker series on a monthly or quarterly basis next year.
The current format of bi-weekly talks will continue till the end of this
school year.
o As Nils will be resigning as chairman in 1-1/2 years, a replacement will
have to be found. If an outside search is required, it will have to
begin soon. In the worst case that a new chairman is not found, Nils
mentioned the worst case scenario of CS being absorbed into EE.
o The time, location, and format of the Faculty Retreat were debated. More
on this later.
#andrew
∂30-Jan-89 0750 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Teaching Strategies
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 89 07:50:09 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sun 29 Jan 89 23:56:31-PST
Message-ID: <xhE4t@SAIL.Stanford.EDU>
Date: 29 Jan 89 2358 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Teaching Strategies
To: faculty@SCORE.Stanford.EDU
∂25-Jan-89 1641 @Score.Stanford.EDU:peyton@polya.Stanford.EDU Teaching Strategies
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Jan 89 16:39:46 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 25 Jan 89 16:09:46-PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA16710; Wed, 25 Jan 89 16:10:56 PDT
Date: Wed, 25 Jan 1989 16:10:53 PST
Sender: "Liam H. Peyton" <peyton@polya.stanford.edu>
From: "Liam H. Peyton" <peyton@polya.stanford.edu>
To: csd@polya.Stanford.EDU
Subject: Teaching Strategies
Message-Id: <CMM.0.87.601776654.peyton@polya.stanford.edu>
The current approach seems to be to cover BOTH extremes, and indeed, anything
that can be remotely qualified as good and worthwhile should be required
before someone is given a Stanford PhD in computer science. Thats why the
program takes 6 2/3 years on average. (For example, the programming project
requirement is there because "every computer science PhD should know how
to program". Which was fine 20 years ago, but these days it seems more
relevant to substitute the phrase "6th grader" for computer science PhD.)
It seems to me that the day has long past when a computer science PhD
should assume empty vessels coming in and computer science complete
vessels going out. As the body of knowledge which is computer
science continues to grow at an accelerated rate, it is not unreasonable
to expect prior knowledge coming in and allow immediate specialization
during the program. Without both the 6 2/3 years will continue to balloon.
So, I would say that Prof. Floyd is absolutely correct in his view - he just
doesnt go far enough. His ideal of a complete professional should be a
PREREQUISITE for admission to the program. Then, one could have a short
apprenticeship to doing research and teaching in the field. In no area
that I know of is a PhD a professional degree (especially medicine) but
it does makes sense to say that one has to be a professional before one can
benefit from a PhD program.
---Liam
I am only sending this to the csd bboard, but anyone may retransmit all
or part of this with or without my name attached.
∂30-Jan-89 0753 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Comps and PhD program
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 89 07:53:34 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sun 29 Jan 89 23:57:47-PST
Message-ID: <LhE5J@SAIL.Stanford.EDU>
Date: 29 Jan 89 2359 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Comps and PhD program
To: faculty@SCORE.Stanford.EDU
∂26-Jan-89 0911 @Score.Stanford.EDU,@polya.Stanford.EDU:postmaster@score.stanford.edu Comps and PhD program
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 89 09:11:25 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 26 Jan 89 09:09:39-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA15959; Thu, 26 Jan 89 09:10:48 -0800
Date: 26 Jan 89 17:10:42 GMT
From: mkatz@Sesame.Stanford.EDU (Morris Katz)
Organization: Stanford University
Subject: Comps and PhD program
Message-Id: <6366@polya.Stanford.EDU>
Sender: postmaster@score.stanford.edu
To: csd@score.stanford.edu
I believe that the first step necessary in evaluating the Comps is to identify
their purpose. For every purpose I have heard stated, I have heard other
faculty members strongly deny that purpose. I suggest that the faculty be
forced (encouraged) to identify the purpose(s) of the Comp. Given that
(those), we can then evaluate whether the Comps actually serve to further the
goals outlined and whether there are other more effective means of achieving
those goals.
As a second issue, the faculty should identify what their goals are for the PhD
program. Are there some set of qualities which they desire to be true of all
individuals holding Stanford Phd's in Computer Science. One can then evaluate
the complete PhD program as to whether it is achieving its goals. I have heard
some faculty members say that research is important. Others have stated that
breadth is important; but, just what is meant by breadth and to what extent is
not clear. Should everybody have to have a minor in some other field in order
to demonstrate true breadth? (This is true at many other universities.) Once
all of the goals of the entire program have been listed, the faculty must
prioritize them since it is clear that no individual will actually meet all of
the possible laudable goals. Given all of the above information, we as members
of the Computer Science Department are then in a position to make reasonable
suggestions as to how the current program should be modified in the interest of
improvement.
Morry Katz
katz@polya.stanford.edu
--
∂30-Jan-89 0756 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: A Comp Retrospective
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 89 07:56:38 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sun 29 Jan 89 23:59:06-PST
Message-ID: <$hP0R@SAIL.Stanford.EDU>
Date: 30 Jan 89 0000 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Re: A Comp Retrospective
To: faculty@SCORE.Stanford.EDU
∂26-Jan-89 0938 @Score.Stanford.EDU,@polya.Stanford.EDU:postmaster@score.stanford.edu Re: A Comp Retrospective
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 89 09:38:41 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 26 Jan 89 09:36:51-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA17168; Thu, 26 Jan 89 09:38:03 -0800
Date: 26 Jan 89 17:37:54 GMT
From: mkatz@Sesame.Stanford.EDU (Morris Katz)
Organization: Stanford University
Subject: Re: A Comp Retrospective
Message-Id: <6369@polya.Stanford.EDU>
References: <6342@polya.Stanford.EDU>
Sender: postmaster@score.stanford.edu
To: csd@score.stanford.edu
In article <6342@polya.Stanford.EDU>, anderson@polya (Jennifer-Ann Anderson)
writes:
>Why can't the comps be more of a diagnostic rather than yet another hoop
>to jump through? We could see what our weak areas are and
>then take the appropriate classes (or perhaps TA the classes).
*************************
To punish a class full of students for a given PhD student's lack of knowledge
is inexcusable. It is bad enough that some faculty members think that merely
passing the Comps qualifies one to teach any introductory Computer Science
class (an appallingly minimal criterion), but this is really a bad idea.
Students deserve a TA who can add something to their learning experience, not
one who is doing his or her best just to keep up.
>
> -- Jennifer Anderson
-- Morry Katz
--
∂30-Jan-89 0759 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: Comps and PhD program
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 89 07:59:48 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sun 29 Jan 89 23:59:13-PST
Message-ID: <xhP0w@SAIL.Stanford.EDU>
Date: 30 Jan 89 0000 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Re: Comps and PhD program
To: faculty@SCORE.Stanford.EDU
∂26-Jan-89 1012 @Score.Stanford.EDU,@polya.Stanford.EDU:postmaster@score.stanford.edu Re: Comps and PhD program
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 89 10:12:20 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 26 Jan 89 10:10:30-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA18762; Thu, 26 Jan 89 10:11:40 -0800
Date: 26 Jan 89 18:11:31 GMT
From: young@polya.Stanford.EDU (R. Michael Young)
Organization: Stanford University
Subject: Re: Comps and PhD program
Message-Id: <6373@polya.Stanford.EDU>
References: <6366@polya.Stanford.EDU>
Sender: postmaster@score.stanford.edu
To: csd@score.stanford.edu
I agree with Morris. It seems the comps enjoy the luxury of being so
ill-defined that no one can say definitely what their content will be,
what their purpose is, what their purpose is not, what kind of grading
criteria will be used, what circumstances, if any, will help someone
who failed to pass all the comps before the end of whetever time
period or what techniques might be viable alternatives.
To have a "procedure" like the comps (I can't call it a milestone,
hurdle, filter, or checkpoint because we can't even agree on whether
the comp is any one of those) without a clear and definitely _policy_
is irresponsible, and to try and deal with such an important issue
without looking first to define their intent seems counterproductive.
-R
--
∂30-Jan-89 0802 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: Comps and PhD program
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 89 08:02:43 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sun 29 Jan 89 23:59:30-PST
Message-ID: <LhP0l@SAIL.Stanford.EDU>
Date: 30 Jan 89 0001 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Re: Comps and PhD program
To: faculty@SCORE.Stanford.EDU
∂26-Jan-89 1017 @Score.Stanford.EDU,@polya.Stanford.EDU:postmaster@score.stanford.edu Re: Comps and PhD program
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 89 10:17:24 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 26 Jan 89 10:15:26-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA19152; Thu, 26 Jan 89 10:16:36 -0800
Date: 26 Jan 89 18:16:24 GMT
From: max@polya.Stanford.EDU (Max Hailperin)
Organization: Stanford University
Subject: Re: Comps and PhD program
Message-Id: <6374@polya.Stanford.EDU>
References: <6366@polya.Stanford.EDU>
Sender: postmaster@score.stanford.edu
To: csd@score.stanford.edu
In article <6366@polya.Stanford.EDU> mkatz@Sesame.Stanford.EDU
(Morris Katz) writes:
>Once all of the goals of the entire program have been listed, the faculty must
>prioritize them since it is clear that no individual will actually meet all of
>the possible laudable goals.
Instead of a prioritized list of goals for the program, the goals can be
treated as a menu of possibilities from which each individual student
(with the advice/consent of his faculty advisor) can choose. The PhD
program, contrary to Katz's (and others') supposition, need not have
*a* purpose, but rather should be flexible enough that each student can
use it to serve whatever purpose suits them.
∂30-Jan-89 0805 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Apprenticeship
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 89 08:05:21 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 30 Jan 89 00:00:02-PST
Message-ID: <LhP1Q@SAIL.Stanford.EDU>
Date: 30 Jan 89 0001 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Apprenticeship
To: faculty@SCORE.Stanford.EDU
∂26-Jan-89 1127 @Score.Stanford.EDU:jbn@glacier.stanford.edu Apprenticeship
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 89 11:27:18 PST
Received: from glacier.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 26 Jan 89 11:25:22-PST
Received: by glacier.stanford.edu; Thu, 26 Jan 89 11:25:41 PST
Date: Thu, 26 Jan 89 11:25:41 PST
From: John B. Nagle <jbn@glacier.stanford.edu>
Subject: Apprenticeship
To: csd-bboard@score.stanford.edu
Pat Hayes writes:
>( I chose the word "apprenticeship"
>carefully, since the closest analogy is with the mediaeval craft
>guilds. One cant learn how to be a smith by attending courses, one
>has to work with iron. )
As I write this, Doug Freund is teaching blacksmithing to design
students over at the foundry in the Mechanical Engineering Department's
Design Division Shops. Students see it done, and then do it themselves.
This is part of the Design Division's determined effort to provide its
students with a clear understanding of the ways by which tangible
things are made, in both a practical and theoretical sense. The
Design Division operates a machine shop, a wood shop, a welding shop,
a foundry, an injection-moulding facility, and a CAD facility for this
purpose. Graduates are ready to design new manufactured objects.
Now this is an area in which an apprenticeship program might seem
to be quite appropriate, in that the transmission of some rather traditional
skills is required, and a learning-by-doing experience is quite necessary.
But the program is not structured in that way. Rather, it is structured
in terms of a sequence of design exercises in various media intended
to teach both creativity and competence.
It's not that you can't learn to do research by attending courses,
it's that CS courses aren't typically about doing research, but rather
about acquiring specific subject matter.
Having been affiliated with both organizations (I have an MSCS and
have been a visiting scholar with the Design Division), I have to say
that the Design Division has a much more coherent vision of what they are
trying to teach their students, and are quite successful at so doing,
unusually so, in that few schools undertake to create product designers
and fewer succeed.
John Nagle
∂30-Jan-89 0808 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: Comps and PhD program
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 89 08:08:23 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 30 Jan 89 00:00:29-PST
Message-ID: <LhP1k@SAIL.Stanford.EDU>
Date: 30 Jan 89 0002 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Re: Comps and PhD program
To: faculty@SCORE.Stanford.EDU
∂26-Jan-89 1145 @Score.Stanford.EDU,@polya.Stanford.EDU:postmaster@score.stanford.edu Re: Comps and PhD program
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 89 11:44:57 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 26 Jan 89 11:42:35-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA22997; Thu, 26 Jan 89 11:19:19 -0800
Date: 26 Jan 89 19:19:05 GMT
From: mkatz@Sesame.Stanford.EDU (Morris Katz)
Organization: Stanford University
Subject: Re: Comps and PhD program
Message-Id: <6375@polya.Stanford.EDU>
References: <6366@polya.Stanford.EDU>, <6374@polya.Stanford.EDU>
Sender: postmaster@score.stanford.edu
To: csd@score.stanford.edu
In article <6374@polya.Stanford.EDU>, max@polya (Max Hailperin) writes:
>In article <6366@polya.Stanford.EDU> mkatz@Sesame.Stanford.EDU
>(Morris Katz) writes:
>>Once all of the goals of the entire program have been listed, the faculty
>>must prioritize them since it is clear that no individual will actually meet
>>all of the possible laudable goals.
>
>Instead of a prioritized list of goals for the program, the goals can be
>treated as a menu of possibilities from which each individual student
>(with the advice/consent of his faculty advisor) can choose. The PhD
>program, contrary to Katz's (and others') supposition, need not have
>*a* purpose, but rather should be flexible enough that each student can
>use it to serve whatever purpose suits them.
It was not my intension to lock all PhD students into a rigid program, but
merely to force the faculty to at least seriously consider what they believe to
be the important constituents of a PhD program. Prioritization should consist
of identify ing those few criterion which are felt to be essential (e.g. a
thesis), as well as a number of those which are desirable (possibly a set from
which students would have to fulfill some reasonable sized subset). The
essence of my ideas is that to discuss improvements before knowing the
objectives is a futile effort.
--
--
∂30-Jan-89 0811 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: Comps and PhD program
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 89 08:11:21 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 30 Jan 89 00:00:53-PST
Message-ID: <LhP2D@SAIL.Stanford.EDU>
Date: 30 Jan 89 0002 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Re: Comps and PhD program
To: faculty@SCORE.Stanford.EDU
∂26-Jan-89 1146 @Score.Stanford.EDU,@polya.Stanford.EDU:postmaster@score.stanford.edu Re: Comps and PhD program
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 89 11:46:15 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 26 Jan 89 11:43:57-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA25336; Thu, 26 Jan 89 11:45:05 -0800
Date: 26 Jan 89 19:44:50 GMT
From: max@polya.Stanford.EDU (Max Hailperin)
Organization: Stanford University
Subject: Re: Comps and PhD program
Message-Id: <6378@polya.Stanford.EDU>
References: <6366@polya.Stanford.EDU>, <6374@polya.Stanford.EDU>, <6375@polya.Stanford.EDU>
Sender: postmaster@score.stanford.edu
To: csd@score.stanford.edu
Let me go on record as saying that I *do* support discussion of program
objectives rather than mere quibling about specific exams or what not.
Let me also clarify my previous point. I did not mean to cast Morry's or
anyone else's ideas as narrow or rigid, and apologize for creating that
impression. What I did mean is this:
Conventional wisdom assigns a purpose to the Ph.D. program. I instead
assign the purpose to the student. The program is a tool, which the
student uses to forge himself into whatever he wants to be. The
department, as caretaker of that tool, has a limited responsibility to
make sure it is not misused. It has a far greater responsibility to
ensure that the tool is versatile enough that people will come to use
it for a variety of purposes.
∂30-Jan-89 0814 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: Apprenticeship
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 89 08:14:04 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 30 Jan 89 00:01:11-PST
Message-ID: <LhP2U@SAIL.Stanford.EDU>
Date: 30 Jan 89 0002 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Re: Apprenticeship
To: faculty@SCORE.Stanford.EDU
∂26-Jan-89 1154 @Score.Stanford.EDU,@polya.Stanford.EDU:postmaster@score.stanford.edu Re: Apprenticeship
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 89 11:54:41 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 26 Jan 89 11:50:26-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA25810; Thu, 26 Jan 89 11:51:27 -0800
Date: 26 Jan 89 19:51:16 GMT
From: max@polya.Stanford.EDU (Max Hailperin)
Organization: Stanford University
Subject: Re: Apprenticeship
Message-Id: <6379@polya.Stanford.EDU>
References: <8901261926.AA23642@polya.Stanford.EDU>
Sender: postmaster@score.stanford.edu
To: csd@score.stanford.edu
In article <8901261926.AA23642@polya.Stanford.EDU> jbn@GLACIER.STANFORD.EDU
(John B. Nagle) writes:
> Pat Hayes writes: . . . "apprenticeship" . . .
> . . . [Mech E design division] . . .
>But the program is not structured in that way. Rather, it is structured
>in terms of a sequence of design exercises in various media intended
>to teach both creativity and competence.
>
> It's not that you can't learn to do research by attending courses,
>it's that CS courses aren't typically about doing research, but rather
>about acquiring specific subject matter.
In the unlikely even that the analogy was lost on anybody: Nagle could
have been describing Knuth's CS 304.
∂30-Jan-89 0817 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU re: Comps and PhD program
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 89 08:17:16 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 30 Jan 89 00:02:38-PST
Message-ID: <LhP3m@SAIL.Stanford.EDU>
Date: 30 Jan 89 0004 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: re: Comps and PhD program
To: faculty@SCORE.Stanford.EDU
∂26-Jan-89 1449 @Score.Stanford.EDU:RWF@SAIL.Stanford.EDU re: Comps and PhD program
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 89 14:49:52 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 26 Jan 89 14:39:58-PST
Message-ID: <xfxjt@SAIL.Stanford.EDU>
Date: 26 Jan 89 1441 PST
From: Robert W Floyd <RWF@SAIL.Stanford.EDU>
Subject: re: Comps and PhD program
To: young@POLYA.Stanford.EDU, csd@Score.Stanford.EDU
[In reply to message from young@polya.Stanford.EDU sent 26 Jan 89 18:11:31 GMT.]
I agree that the purpose of the comp is unclear, but one thing
is clear to me historically: the comp was instituted as both final
filter on an exception basis (our admissions procedure admits very
few students who prove unable to pass it, mainly students whose
prior education is remote in place or time) and as our sole way
of enforcing a breadth requirement (we dropped all course
requirements at around the time we instituted the comp). The original
intent was that the comp be integrative, showing ability to coordinate
knowledge from the branches of CS; I think the current format
actually discourages design of such exams. I expect that the comp.
committee will be examining this question.
I think the loss of a sense of purpose is inherent in the continual
turnover in the comp committee. We should have a committee with
long term membership. This would be cruel and unusual punishment
if nonmember faculty do not contribute proposed questions and
grading.
In general, in fact, I think the current size of the department
calls for specialization in long term committee assignments,
especially to the PhD, MS, admissions, and comp committees.
This is happening to some extent already. Not having been
on the comp committee in the current exam format, I found that
my judgment was inaccurate about the timing difficulties
(though I pushed the exam in the right direction, it wasn't far enough).
∂30-Jan-89 0820 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU re: Comps and PhD program
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 89 08:20:16 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 30 Jan 89 00:02:59-PST
Message-ID: <LhP4B@SAIL.Stanford.EDU>
Date: 30 Jan 89 0004 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: re: Comps and PhD program
To: faculty@SCORE.Stanford.EDU
∂26-Jan-89 1450 @Score.Stanford.EDU:RWF@SAIL.Stanford.EDU re: Comps and PhD program
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Jan 89 14:50:31 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 26 Jan 89 14:47:17-PST
Message-ID: <18fy1p@SAIL.Stanford.EDU>
Date: 26 Jan 89 1448 PST
From: Robert W Floyd <RWF@SAIL.Stanford.EDU>
Subject: re: Comps and PhD program
To: max@POLYA.Stanford.EDU, csd@Score.Stanford.EDU
[In reply to message from max@polya.Stanford.EDU sent 26 Jan 89 19:44:50 GMT.]
To add to Max's message about purposes, any human institution
is used by people to achieve their own purposes, whatever the
purposes of its founders. It is difficult to anticipate
what purposes the users will try to achieve until experience
is gained. The cleverer the users, the more ways they will
game the system. Good intentions guarantee nothing.
This is why rehabilitation as a goal of incarceration
has hisorically failed; noone has invented a version that
does not lend itself to gaming for very different purposes.
Not that that exampple has much to do with graduate study.
∂30-Jan-89 0822 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Comprehensive Exams
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 89 08:22:33 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 30 Jan 89 00:03:34-PST
Message-ID: <LhP4f@SAIL.Stanford.EDU>
Date: 30 Jan 89 0005 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Comprehensive Exams
To: faculty@SCORE.Stanford.EDU
∂27-Jan-89 0805 @Score.Stanford.EDU:sankar@mycroft.STANFORD.EDU Comprehensive Exams
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Jan 89 08:05:07 PST
Received: from mycroft.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Fri 27 Jan 89 08:03:21-PST
Received: by mycroft.STANFORD.EDU (3.2/4.7); Fri, 27 Jan 89 08:01:33 PST
Date: Fri, 27 Jan 89 08:01:33 PST
From: sankar@mycroft.STANFORD.EDU (Sriram Sankar)
To: csd@score
Subject: Comprehensive Exams
As someone who has taken these exams 5 years ago and not kept track of the
changes that have taken place since I may be a bit out of date. But anyway ...
Given a choice between having to take required courses and the comprehensive
exam, I would prefer the latter. My view of the comprehensive exam is as a
mechanism to decide whether or not the student has sufficient background to
embark on a PhD, given the variety of backgrounds from which new students
enroll.
I believe it is still possible to be admitted to the CS PhD program with
no formal background in CS. For example, you could have majored in math
or EE or something else for that matter. At my time, we were not
required to take the GRE subject test in CS. We could take it in Math
or Engineering also. So those without the background could take the
courses and then take the exam, while others could take the exam directly.
If the comp. syllabus and the way the exam is conducted still achieves
the above purpose, I am happy.
Sriram.
∂30-Jan-89 0826 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Sr Staff Meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 89 08:25:56 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 30 Jan 89 00:06:09-PST
Message-ID: <xhP7s@SAIL.Stanford.EDU>
Date: 30 Jan 89 0007 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Sr Staff Meeting
To: faculty@SCORE.Stanford.EDU
∂28-Jan-89 1429 @Score.Stanford.EDU:bhayes@polya.Stanford.EDU Sr Staff Meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Jan 89 14:29:07 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sat 28 Jan 89 14:27:21-PST
Received: from LOCALHOST by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA11965; Sat, 28 Jan 89 14:28:25 -0800
Message-Id: <8901282228.AA11965@polya.Stanford.EDU>
To: csd-bboard@polya.Stanford.EDU
Subject: Sr Staff Meeting
Date: Sat, 28 Jan 89 14:28:24 -0800
From: bhayes@polya.Stanford.EDU
Robotics will be growing into Poplar Hall, over by Pine Hall. It's
either the 9th or 10th computer science site, but people are losing
count. This may open some space for theory people in Jacks, and a good
thing too, since new faculty and visitors may cause some students to be
evicted from MJH outside offices. Sorry, folks...
The new building is meeting with some indecision. The presentation to
the Trustees may be delayed until April at the decision of the Provost.
Faculty retreat is coming on May 5th, 6th, and 7th. Slip out and have
some fun that weekend if your advisor is leaving town.
James Wilson of administrative computing will be leaving that post to
start on his own company.
The University is trying to pass a new "tax on gifts". As you might
guess, lots of faculty object. It could cause a lot of problems for
the Forum.
Which is, of course, coming up very soon. The book store will be
offering a 10% discount on CS books by Stanford faculty, and a book
signing. They'll make wonderful Christmas gifts.
Elizabeth Buss, the Forum's Multimedia Coordinator, will also be
leaving soon after this years Forum. She's off to school, dispite
having seen what grad school is like. Last chance to warn her...
Thursday the 16th from 4:30 to 6 is the closing reception for Forum,
and all are invited. A chance to schmooze with big guns from industry
and see the sort of food that makes fat cats fat.
The Forum is disappointed in the turnout of resumes for the
undergraduate book. We DO have undergraduates, you know. We had to
sweet-talk Carolyn into not discontinuing the service for
undergraduates. Folks use these books for finding employees, summer
and fulltime, and for looking for people for fellowships. Undergrads,
even if you're not looking for a job, keep a resume with Carolyn so
she'll keep doing the book. Likewise grad students.
-b
∂30-Jan-89 0830 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU A Comp Retrospective
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 89 08:30:12 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 30 Jan 89 01:05:35-PST
Message-ID: <$hPQQ@SAIL.Stanford.EDU>
Date: 30 Jan 89 0035 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: A Comp Retrospective
To: faculty@SCORE.STANFORD.EDU
∂25-Jan-89 1236 usenet@polya.stanford.edu A Comp Retrospective
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Jan 89 12:34:29 PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA02515; Wed, 25 Jan 89 12:33:40 PDT
Date: 25 Jan 89 20:33:32 GMT
From: anderson@polya.Stanford.EDU (Jennifer-Ann Anderson)
Organization: Stanford University
Subject: A Comp Retrospective
Message-Id: <6342@polya.Stanford.EDU>
Sender: usenet@polya.stanford.edu
To: phd-program@polya.stanford.edu
I just finished taking the comps, and found that there are two
things that bothered me the most about the exams: the randomness
of the difficulty level, and the fact that we could get booted out
of the program for not passing.
This year's Theory Comp is a case in point. It was *significantly*
more difficult than previous theory exams. Consider a second
year student who only has one chance left at passing. He could
get handed an exam like this one, fail, and get thrown out of the
program. On the other hand, he could end up with a reasonable exam,
pass, and be allowed to stay. It's completely random.
Although, this scenario is a bit extreme (I realize that very few
people actually get thrown out because of comps) the fact that it
could happen under our present system is cause for concern.
Please note that I'm not protesting how hard the comps are,
just the variability from exam to exam. If the powers-that-be
think Stanford students should know certain things about computer
science that's fine with me, but if staying in the program is
contingent upon passing these exams, keep them consistent.
But, you might say, the comps are graded on a curve so that should
offset any fluctuations in the difficulty level.
I don't think grading an exam like this on a curve helps much.
How can you judge the abilities of students by comparing test
scores when the mean is 35-45% (just a guess as to what the
mean of the theory comp will be)? All that tells me is that the exam
was much harder than the students expected. Also, curving the
exam may breed a negative form of competition among the students --
"I hope 7 people do worse than me so that I can be in the top
2/3rds and pass". Not a healthy attitude towards your fellow comp-takers.
Well, I can't complain this much without offering some sort of
suggestion.
Why can't the comps be more of a diagnostic rather than yet another hoop
to jump through? We could see what our weak areas are and
then take the appropriate classes (or perhaps TA the classes).
This way, we would have a good idea of how much work we will need
to put in to pass the breadth requirement. With the comps, you
could study for an unlimited amount of time and still not know
what you're going to be up against.
With the present system, we spend too much time worrying about comps,
and not enough thinking about research. But what do you expect from
students when you tell them that they have to pass these exams
in two years or they're out? Although we'd much rather start in
on research early, the comps end up becoming a priority.
Even if the comp becomes more of a diagnostic, we will still
have the problem of inconsistency from exam to exam. However,
the stakes will be much lower (just taking a class or two as
opposed to being asked to leave the program).
I'd like to hear what others think.
-- Jennifer Anderson
∂30-Jan-89 0833 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: A Comp Retrospective
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 89 08:33:41 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 30 Jan 89 01:05:38-PST
Message-ID: <$hPRE@SAIL.Stanford.EDU>
Date: 30 Jan 89 0036 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Re: A Comp Retrospective
To: faculty@SCORE.STANFORD.EDU
∂25-Jan-89 2237 usenet@polya.stanford.edu Re: A Comp Retrospective
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Jan 89 22:37:41 PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA03944; Wed, 25 Jan 89 22:37:12 -0800
Date: 26 Jan 89 06:37:07 GMT
From: robert@polya.Stanford.EDU (James R. Kennedy)
Organization: Stanford University
Subject: Re: A Comp Retrospective
Message-Id: <6362@polya.Stanford.EDU>
References: <6342@polya.Stanford.EDU>
Sender: usenet@polya.stanford.edu
To: phd-program@polya.stanford.edu
In article <6342@polya.Stanford.EDU> anderson@polya.Stanford.EDU (Jennifer-Ann Anderson) writes:
> suggestion.
> Why can't the comps be more of a diagnostic rather than yet another hoop
> to jump through? We could see what our weak areas are and
> then take the appropriate classes (or perhaps TA the classes).
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
Good heavens!! What are you saying?!?!? THIS PHENOMENON COULD BE WHY
I'M FAILING COMPS!!! Maybe if I had had TA's that were COMPETENT,
rather than TA's who were teaching me something because they didn't
know it themselves, I would have nothing to worry about on the
comps...
> I'd like to hear what others think.
You asked...
Sorry this is so terse -- I really agree with most of the posting. But
I think it's really important that people learn something BEFORE they
teach it, rather than after.
-- Robert
∂30-Jan-89 0837 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: A Comp Retrospective
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 89 08:37:12 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 30 Jan 89 01:05:41-PST
Message-ID: <$hPRR@SAIL.Stanford.EDU>
Date: 30 Jan 89 0036 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Re: A Comp Retrospective
To: faculty@SCORE.STANFORD.EDU
∂25-Jan-89 2239 usenet@polya.stanford.edu Re: A Comp Retrospective
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Jan 89 22:39:35 PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA04049; Wed, 25 Jan 89 22:39:07 -0800
Date: 26 Jan 89 06:38:59 GMT
From: robert@polya.Stanford.EDU (James R. Kennedy)
Organization: Stanford University
Subject: Re: A Comp Retrospective
Message-Id: <6363@polya.Stanford.EDU>
References: <6342@polya.Stanford.EDU>, <6362@polya.Stanford.EDU>
Sender: usenet@polya.stanford.edu
To: phd-program@polya.stanford.edu
In article <6362@polya.Stanford.EDU> robert@polya.Stanford.EDU (James R. Kennedy) writes:
> I think it's really important that people learn something BEFORE they
> teach it, rather than after.
↑↑↑↑↑
Oops. I meant "during." Sorry.
-- Robert
∂30-Jan-89 0842 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: More-on the Faculty Lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 89 08:42:35 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 30 Jan 89 01:05:49-PST
Message-ID: <$hPPx@SAIL.Stanford.EDU>
Date: 30 Jan 89 0034 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Re: More-on the Faculty Lunch
To: faculty@SCORE.STANFORD.EDU
∂24-Jan-89 2139 usenet@polya.stanford.edu Re: More-on the Faculty Lunch
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Jan 89 21:39:52 PST
Received: by polya.Stanford.EDU (5.59/25-eef) id AA05278; Tue, 24 Jan 89 21:39:24 PDT
Date: 25 Jan 89 05:39:12 GMT
From: gangolli@wolvesden.Stanford.EDU (Anil R. Gangolli)
Organization: Stanford University
Subject: Re: More-on the Faculty Lunch
Message-Id: <6331@polya.Stanford.EDU>
References: <6326@polya.Stanford.EDU>
Sender: usenet@polya.stanford.edu
To: phd-program@polya.stanford.edu
I agree with the point of view that we should be more research-oriented.
I also agree with an old message on the csd.bboard that suggested that
many students are more motivated on entry to the program than after
quals; certainly that describes me, and while I can only speak of with
assurance of myself, I have seen evidence of more of that than there
should be. We should make a real department-wide effort to remedy
that, but I know that at least in my case, my sporadic motivational
slumps could not wholly be attributed to the department or the
program.
We have not devoted enough real effort to get ourselves and the
department moving again. The way to do that is to work hard at
research, keeping up on it and trying to obtain new results, and to
talk a lot to your colleagues in an effort to collaborate. I think
this is just much harder to do (at least at start-up time) than we
come in thinking. But I think that is the only way. Everything the
faculty does to engender this is likely to help. Anything we do to
the phd program that doesn't is unlikely to help.
Students who have not passed the comp and qual have stronger but less
enlightened opinions on the utility of exams, or the lack thereof.
Having passed both, and NOT being amongst the brightest in mine or the
immediately succeeding classes, I know it was both possible and worth
SOME while. The comp has since gotten both broader and deeper, (read
harder), to the detriment of the program. That is perhaps the only
current legitimate complaint about the program itself. The rest has
to do with us, the students and the faculty, and I don't think
procedural/programmatic methods will provide any solution.
--anil.
∂30-Jan-89 0850 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Forwarding Mail
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 89 08:50:53 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 30 Jan 89 08:05:32-PST
Message-ID: <4hW1#@SAIL.Stanford.EDU>
Date: 30 Jan 89 0759 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Forwarding Mail
To: faculty@SCORE.STANFORD.EDU
I have twice recently re-mailed messages from various places to the CS
faculty mailing list (faculty@score). These messages were taken from
the CSD bulletin board (CSD@SAIL, CSD@SCORE, csd.bboard on the UNIX machines
including Polya) and from the PhD program BBoard.
I mailed them out because I'm not sure that everyone was aware that these
existed as separate entities, and I thought the content was useful in the
context of current discussions.
I want people to know that these are my my personal opinions, but those
of other people forwarded on.
If there is sentiment that I should stop doing this, please let me know.
(I won't do it forever anyway, nor in general.) If you would like to know
how to read these BBoards for yourself, perhaps James Wilson can provide
you with instructions for Score or Polya (I'll be happy to provide them
for SAIL).
Arthu
∂30-Jan-89 0857 @Score.Stanford.EDU:hayes@arisia.xerox.com rec.humor.funny
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 89 08:56:58 PST
Received: from arisia.Xerox.COM by SCORE.STANFORD.EDU with TCP; Mon 30 Jan 89 08:21:52-PST
Received: by arisia.Xerox.COM
(5.59++/IDA-1.2.6) id AA27708; Mon, 30 Jan 89 00:29:46 PST
Date: Mon, 30 Jan 89 00:29:46 PST
From: Pat Hayes <hayes@arisia.xerox.com>
Message-Id: <8901300829.AA27708@arisia.Xerox.COM>
To: JMC@SAIL.STANFORD.EDU
Cc: su-etc@SAIL.STANFORD.EDU, faculty@SCORE.STANFORD.EDU
In-Reply-To: John McCarthy's message of 29 Jan 89 14:31 PST <LhraH@SAIL.Stanford.EDU>
Subject: rec.humor.funny
Dear John
I think that your not having tried out the "joke" on a Scot is
revealing. After all, it makes no attack on the character of the
Jewish gentlemen: he indulges, ironically, in a harmless prank which
results in his being promptly murdered by the Scot, motivated
presumably by Scottish meanness, coldbloodedness and temper. This is
just the sort of dangerous stereotyping which Gorin and Sack complain
of, and is liable to lead to the sort of anti-Scottish feeling which
gave rise to Culloden. AS someone who numbers many Scots among his
friends, and lived there for several years, I think I can say that any
true Scottish Nationalist would find this attempt at humor quite
unacceptable in any civilised publication. If Stanford is to be a
place where one can eat haggis proudly, then we must take this sort of
neo-English hatred seriously.
Pat Hayes
∂30-Jan-89 1118 @Score.Stanford.EDU:tom@polya.Stanford.EDU Large automated NFS file/archive server
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 89 11:18:29 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 30 Jan 89 11:14:27-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA00820; Mon, 30 Jan 89 09:43:12 -0800
Date: Mon, 30 Jan 89 09:43:12 -0800
From: Tom Dienstbier <tom@polya.Stanford.EDU>
Message-Id: <8901301743.AA00820@polya.Stanford.EDU>
To: faculty@polya.Stanford.EDU, g.gorin@othello, hansen@sierra,
su-computers@polya.Stanford.EDU
Subject: Large automated NFS file/archive server
On February 15th, in room 252, Margaret Jacks Hall, from 1:30 to 3:00,
Ephoch Systems will be providing a 60-minute technical presentation on
its Epoch-1 InfiniteStorage Server, a high-capacity, high performance,
and fully automated NFS file server system for technical workstation
networks experiencing a chronic shortage of Winchester disk space.
The Epoch-1 features a hierarchical storage architecture that transparently
integrates optical disk drive and jukeboxes into a high-speed Winchester
disk system. The company will explain how it has applied virtual memory
concepts to disk storage to achieve capacity and cost advantages of optical
disks yet operate with the look and feel of an all-magnetic disk file server.
The company will also discuss its multiprocessor architecture for high
performance NFS file access, and its online backup facility that allows
for unattended backups while the system is serving workstation users.
Tom Dienstbier
CSDCF
-------
∂30-Jan-89 1124 @Score.Stanford.EDU:Mailer@SAIL.Stanford.EDU misquote
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 89 11:24:50 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 30 Jan 89 11:17:56-PST
Message-ID: <1dhYkW@SAIL.Stanford.EDU>
Date: 30 Jan 89 1117 PST
From: John McCarthy <JMC@SAIL.Stanford.EDU>
Subject: misquote
To: su-etc@SAIL.Stanford.EDU, faculty@SCORE.STANFORD.EDU
A search for the word MOTIVATING in su-etc revealed that today's
Daily's supposed quote from me was from Joseph Jacobs, a PhD
student in computer science. That isn't the only incompetence
shown by the Stanford Daily in this story. Since I attempted to
distinguish between what the University has a legal right to do
and what the traditions of academic freedom require, I lost badly
by this.
∂30-Jan-89 1142 @Score.Stanford.EDU,@polya.Stanford.EDU:TAJNAI@Score.Stanford.EDU Re: Large automated NFS file/archive server
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 89 11:42:07 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 30 Jan 89 11:37:58-PST
Received: from Score.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA08300; Mon, 30 Jan 89 11:38:43 -0800
Date: Mon 30 Jan 89 11:30:23-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Re: Large automated NFS file/archive server
To: tom@Polya.Stanford.EDU, faculty@Polya.Stanford.EDU,
g.gorin@Macbeth.Stanford.EDU, hansen@Sierra.Stanford.EDU,
su-computers@Polya.Stanford.EDU
In-Reply-To: <8901301743.AA00820@polya.Stanford.EDU>
Message-Id: <12466733125.23.TAJNAI@Score.Stanford.EDU>
Tom, that is right in the middle of the Computer Forum 21st Annual meeting.
Could the presentation date be changed?
Carolyn
-------
∂30-Jan-89 1225 @Score.Stanford.EDU:katiyar@polya.Stanford.EDU winter potluck (volunteer wanted)
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 30 Jan 89 12:25:07 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 30 Jan 89 12:21:16-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA12056; Mon, 30 Jan 89 12:22:22 -0800
Date: Mon, 30 Jan 1989 12:22:19 PST
Sender: "Dinesh H. Katiyar" <katiyar@polya.stanford.edu>
From: Potluck Committee <katiyar@polya.stanford.edu>
To: faculty@score, research-associates@score, secretaries@score
Subject: winter potluck (volunteer wanted)
Message-Id: <CMM.0.87.602194939.katiyar@polya.stanford.edu>
It has become a tradition within the department to hold a
Winter Quarter potluck every year. In the past, these events have been
hosted by faculty members and research associates who have graciously
volunteered their homes for an evening.
Plans are underway to continue with the traditional potluck,
but a location for this year's event has not yet been found. If you
are interested in serving as this year's host, please let us know.
The only timing constraint is that the potluck should take place some
time soon after midterms (the following dates seem quite appropriate -
17th,18th,24th or 25th of February).
As the organizational details of the event will all be handled
by the Student Social Committee, the inconvenience to the host should
be kept to a minimum. Thanks!
Jennifer Anderson
anderson@polya
Jaikumar Ramanathan
jaikumar@polya
Dinesh Katiyar
katiyar@polya
∂30-Jan-89 1336 LOGMTC-mailer Carl Gunter talk 2/8
Received: from ra.stanford.edu by SAIL.Stanford.EDU with TCP; 30 Jan 89 13:36:09 PST
Received: by ra.stanford.edu (5.59/25-eef) id AA02712; Mon, 30 Jan 89 13:34:49 PDT
Date: Mon, 30 Jan 89 13:34:49 PDT
From: John Mitchell <jcm@ra.stanford.edu>
Message-Id: <8901302134.AA02712@ra.stanford.edu>
To: csd@score, logmtc@sail
Subject: Carl Gunter talk 2/8
INHERITANCE AND EXPLICIT COERCION
speaker:
Carl Gunter (Penn CIS)
work joint with:
Val Breazu-Tannen (Penn CIS)
Thierry Coquand (INRIA)
Andre Scedrov (Penn Mathematics)
time and place:
Wed Feb 8 at 4:15 PM in MJH 352
We present a method for providing semantic interpretations for
languages which feature INHERITANCE in the framework of statically
checked, rich type disciplines. We illustrate our approach on an
extension of the language Fun of Cardelli and Wegner, which we
interpret via a translation into an extended polymorphic lambda
calculus. Our approach interprets inheritances in Fun as COERCION
FUNCTIONS already DEFINABLE in the target of the translation. Existing
techniques in the theory of semantic domains can be then used to
interpret the extended polymorphic lambda calculus, thus providing
many models for the original language. Our method allows the
simultaneous modeling of PARAMETRIC POLYMORPHISM, RECURSIVE TYPES, and
INHERITANCE, something that was regarded as problematic because of the
seemingly contradictory characteristics of inheritance and type
recursion on higher types.
We identify the main difficulty in providing interpretations for
explicit type disciplines featuring inheritance, namely that programs
can type-check in more than one way. Since interpretations
follow the type-checking derivations, COHERENCE theorems are required,
(that is, one must prove that the meaning of a program does not depend on the
way it was type-checked), and we do prove them for our semantic method.
Interestingly, proving coherence in the presence of recursive types,
variants, and abstract types forced us to reexamine fundamental equational
properties that arise in proof theory (in the form of commutative reductions)
and domain theory (in the form of strict vs. non-strict functions).
∂31-Jan-89 0132 X3J13-mailer Comments on the Character proposal dated January 1, 1989
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 31 Jan 89 01:31:58 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03960g; Tue, 31 Jan 89 01:21:13 PST
Received: by bhopal id AA14594g; Tue, 31 Jan 89 01:23:28 PST
Date: Tue, 31 Jan 89 01:23:28 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901310923.AA14594@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: Baggins@IBM.COM, CL-Characters@SAIL.STANFORD.EDU, X3J13@SAIL.STANFORD.EDU,
Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM,
KMP@STONY-BROOK.SCRC.Symbolics.COM,
Palter@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: David A. Moon's message of Tue, 24 Jan 89 14:46 EST <19890124194625.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Comments on the Character proposal dated January 1, 1989
re:
Date: Tue, 24 Jan 89 14:46 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Comments on the Character proposal dated January 1, 1989
. . . what to do about the
SCHAR, SBCHAR, and SGCHAR mess. First of all, you only need two functions,
not three, because there are only two specified specialized representations.
SCHAR should be for what I've called SIMPLE-STRING, SBCHAR should be
for SIMPLE-BASE-STRING, and SGCHAR is not needed. (In fact I would prefer
to remove all of the specialized versions of AREF from the language, in
favor of THE or type declarations, but I know that would only pass over
some peoples' dead bodies so I won't push it.)
. . .
You might be surprised at the kinds of people who really don't care
about whether or not names for the specialized versions of AREF are
defined in the portable languages. Me, for one.
But what I am very leary about is a definition of an important data
type that is too wishy-washy to be portable. SIMPLE-BASE-STRING may be
in this category. By way of explanation, let me draw the parallel with
some numeric types.
Ostensibly, FIXNUM is in this non-portable category, since up until the
Hawaii meeting, there wasn't even any requirement in the language the
type FIXNUM mean anything at all (i.e., it could be the null subset of
INTEGER). At least now (TYPEP x 'FIXNUM) will imply that <x> is useful
for array/vector indices. For example, the following very reasonable
program might work in implementation A, but fail in implementation B,
*** merely because of the variance of the FIXNUM datatype between the
two implementations ***:
(defun fills-out-p (i b)
;; Ascertain whether bit 'i' of the bit vector 'b' is the same as
;; all the remaining bits (in the higher bit positions).
(check-type i fixnum)
(check-type b simple-bit-vector)
(locally (declare (fixnum i) (simple-bit-vector b))
;; Declarations for "fast, open-coding"
(or (>= i (length b))
(null (position (logxor 1 (aref b i)) ;bit 'i', "inverted"
b
:start (the fixnum (1+ i)))))))
(setq i (position 1 <long-bit-vector>)) ==> say, 100000
(fills-out-p <long-bit-vector> i)
Given our resolution passed in Hawaii about "tightening" the definition
of the type FIXNUM, the above program is now fully portable. True,
there are still some areas of the type FIXNUM that aren't portable;
but the situation isn't nearly as bad as it was before.
Contrast this with the situation regarding the type FLOAT. Although
there are many aspects of non-portability regarding the _use_ of
floating point numbers, there is no permitted variance in the definition
of the type FLOAT. It is never permissible, for example, for one
implementation to implement the FLOAT datatype as lists of integers,
and another to implement it as some low-level primitive datatype.
Thus if a user's "declaration" (CHECK-TYPE X FLOAT) fails in one
implementation, but works in another, it is not due to an inherent
weakness in the specification of the type FLOAT.
As I pointed out during the Hawaii meeting, the types SIMPLE-BASE-STRING
and SIMPLE-GENERAL-STRING contain all the seeds of disaster that the
original definition of FIXNUM did. I would almost rather not see them
put into the language at all if there isn't some minimal statement of
portability about them. The question is: "Is it worth it to make these
types be part of the portable language?". The answer to that will depend
on whether or not there are serious contenders for "optimization". It
is my current belief that Lucid's optimization strategies for STRINGs are
_not_ particularly dependent on having a distinction between SIMPLE-STRING
and SIMPLE-BASE-STRING. I.e., we considered the problem some time ago,
and decided that we could "swallow" a union type, if necessary, for
SIMPLE-STRING, given that the union was only concerning one of two
primitive element types.
So, now, the question is: What implememtations -- current, or seriously
conceived -- would benefit greatly from a portable definition of the
type SIMPLE-BASE-STRING? Let them come forward now, or for the next
few years hold their peace.
-- JonL --
∂31-Jan-89 0942 STAGER@Score.Stanford.EDU Autumn Quarter Tau Beta Pi
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 31 Jan 89 09:42:50 PST
Date: Tue 31 Jan 89 09:39:29-PST
From: Claire Stager <STAGER@Score.Stanford.EDU>
Subject: Autumn Quarter Tau Beta Pi
To: faculty@Score.Stanford.EDU
Office: CS-TAC 29, 723-6094
Message-ID: <12466975081.17.STAGER@Score.Stanford.EDU>
The Autumn Quarter Tau Beta Pi course survey results have arrived, and will
be delivered to your mailboxes later today.
Claire
-------
∂31-Jan-89 1357 CL-Characters-mailer Comments on the Character proposal dated January 1, 1989
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 31 Jan 89 13:57:06 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 531105; Tue 31-Jan-89 16:53:00 EST
Date: Tue, 31 Jan 89 16:53 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Comments on the Character proposal dated January 1, 1989
To: Jon L White <jonl@lucid.com>
cc: Baggins@IBM.COM, CL-Characters@SAIL.STANFORD.EDU, X3J13@SAIL.STANFORD.EDU,
Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM,
Palter@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <8901310923.AA14594@bhopal>
Message-ID: <19890131215325.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Maybe I shouldn't reply to this, since the content doesn't seem to be
directed to me, but on the other hand I was the only non-CC recipient.
Date: Tue, 31 Jan 89 01:23:28 PST
From: Jon L White <jonl@lucid.com>
....
But what I am very leary about is a definition of an important data
type that is too wishy-washy to be portable. SIMPLE-BASE-STRING may be
in this category....
As I pointed out during the Hawaii meeting, the types SIMPLE-BASE-STRING
and SIMPLE-GENERAL-STRING contain all the seeds of disaster that the
original definition of FIXNUM did.
I'm afraid I don't understand your comment. What's inadequately specified
about SIMPLE-BASE-STRING? Is the problem with the SIMPLE part or with
the BASE part, i.e. are you complaining that SIMPLE arrays aren't well
enough specified, or that the BASE-CHARACTER element-type isn't well
enough specified, or something else?
It
is my current belief that Lucid's optimization strategies for STRINGs are
_not_ particularly dependent on having a distinction between SIMPLE-STRING
and SIMPLE-BASE-STRING. I.e., we considered the problem some time ago,
and decided that we could "swallow" a union type, if necessary, for
SIMPLE-STRING, given that the union was only concerning one of two
primitive element types.
I find this rather surprising, although it's really not my place to question
it. You really don't generate just a move.b instruction followed by some kind
of instruction to add in the type bits, on 68000's, for aref of a simple
1-dimensional array of base characters, at highest speed optimization level
and lowest safety optimization level? Instead you generate some kind of type
check followed by branches to either a move.b or a move.l depending on the
string's element type?
Answering the first part is much more important than answering the second
part, in fact maybe I didn't really care about the second part anyway.
∂31-Jan-89 1405 misha@polya.Stanford.EDU This week's AFLB
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 31 Jan 89 14:04:57 PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA22680; Tue, 31 Jan 89 14:01:54 -0800
Date: Tue, 31 Jan 89 14:01:54 -0800
From: Michael Kharitonov <misha@polya.Stanford.EDU>
Message-Id: <8901312201.AA22680@polya.Stanford.EDU>
To: aflb-all@polya.Stanford.EDU
Subject: This week's AFLB
The next AFLB will be this Thursday at 12:30 in room 352.
Status: RO
Arvind Raghunathan from Berkeley will speak about
A CONSTRUCTIVE RESULT FROM GRAPH MINORS: LINKLESS EMBEDDINGS
We consider the problem of checking whether a graph can be embedded
in 3-space such that no collection of vertex disjoint cycles is
topologically linked. The Robertson-Seymour theory of graph minors is
applicable to this problem and guarantees the existence of an O(n↑3)
algorithm for this decision problem. However, not even a finite time
decision procedure was explicitly known for this problem.
We exhibit a small set of forbidden minors for linkless emebddable
graphs and show that any graph with these minors cannot be embedded
without linked cycles. We further establish that any graph which does
not contain these minors is embeddable without linked cycles. Thus, we
demonstrate an O(n↑3) algorithm for the decision problem. This is one
of the first problems for which a polynomial time algorithm has been
constructed after it was shown that such an algorithm must exist.
An important consequence of our work is a proof that a linkless
embeddable graph is also knotless embeddable. We also show that
a graph which is embeddable without any two cycles being linked is
linkless embeddable. Motivated by these results, we define the notion of
a "good" three-dimensional embedding of a graph and show that a graph
has a good embedding if and only if it is linkless embeddable. This
notion of a good embedding gives us a finite time alogrithm to
actually embed a graph without linked cycles, if such an embedding
exists.
(This is joint work with Rajeev Motwani and Huzur Saran)
-----------------------------------------------------------------
Next week we'll have two AFLB meetings again. On Tuesday at 4:15 in
room 352 A. Razborov from Moscow will speak on the method of approximations
for boolean circuit complexity.
∂31-Jan-89 1528 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu sorting on nxn mesh
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 31 Jan 89 15:28:23 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA28457; Tue, 31 Jan 89 15:27:19 -0800
Message-Id: <8901312327.AA28457@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 31 Jan 89 15:26:55 PST
Received: by BYUADMIN (Mailer R2.01A) id 6131; Tue, 31 Jan 89 16:25:19 MST
Date: Tue, 31 Jan 89 17:07:54 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Hartmut Schmeck <NIP77%DKIUNI0.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Hartmut Schmeck <NIP77%DKIUNI0.BITNET@forsythe.stanford.edu>
Subject: sorting on nxn mesh
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
In the research group on algorithms for VLSI at the University of Kiel (FRG)
we studied the problem of sorting on an nxn mesh quite intensively.
The algorithm mentioned by Koloutsakis is a special case of a
partition sort algorithm (see H. Schroeder,"Partition Sorts for VLSI," Proc.
GI-13. Jahrestagung, Hamburg, Oct. 1983, Informatik-Fachberichte 73, Springer
Verlag, 101-116 (1983)). We do not know of any partition sort
algorithm (i.e. an algorithm sorting repeatedly the blocks of a fixed
sequence of partitions, where all the blocks have constant size and
all the elements of a block have constant distance) having a worst case
time less than O(n*n), although simulations on random sequences showed
a sorting time of O(n).
A bad case for Koloutsakis algorithm is the following:
000000000000
000010000000
000011000000
000111100000
000111110000
001111111000
001111111100
011111111110
011111111111
111111111111
111111111111
111111111111
We call it "sand dune", because it takes a long time (O(n*n)) before
the "sorting wind" has flattened the dune. We do not have a formal
proof so far that every partition sort algorithm has a worst case
time of Omega(n*n).
Hartmut Schmeck, Institut f. Informatik, Universitaet Kiel,
D-2300 Kiel, F. R. Germany
e-mail: NIP77@DKIUNI0.BITNET
∂31-Jan-89 2321 @Score.Stanford.EDU:ag@pepper.stanford.edu acquiring a multiprocessor
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 31 Jan 89 23:21:52 PST
Received: from pepper.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 31 Jan 89 23:18:18-PST
Received: by pepper.stanford.edu (5.57/Ultrix2.4-C)
id AA10622; Tue, 31 Jan 89 23:15:49 PST
Message-Id: <8902010715.AA10622@pepper.stanford.edu>
To: faculty@score.Stanford.EDU
Subject: acquiring a multiprocessor
Date: Tue, 31 Jan 89 23:15:47 PST
From: ag@pepper.stanford.edu
During the last few months I have been trying to persuade AIR (Academic
Information Resources) to acquire a multiprocessor. I primarily need it
for the CS411 course (Parallel Computer Architectures and Programming) that
I teach every winter quarter. The course has an enrollment of 50+ students,
and requires several programming assignments and a final project to be done
on a multiprocessor. For the past two years I have been using our research
machine, an Encore Multimax with 16 processors, to provide the parallel
computing cycles. The use of the Encore by CS411 students hampers our
research on that machine, and these coursework cycles should really be
provided by AIR.
Ralph Gorin (Director of AIR) has responded favorably so far, but he is
interested in knowing how many other faculty members would also find such a
resource useful. The kind of machine we have in mind would have about 10-30
processors, provide for shared memory, and have a UNIX-like operating
system. The question we would like to have answered is:
For the courses that you are currently teaching or are likely to develop
within the next couple of years, would you use such a multiprocessor?
Please mail your responses to ag@pepper and I will collate and forward them
to Ralph Gorin. Thanks. --- Anoop.
∂01-Feb-89 0910 HEMENWAY@Score.Stanford.EDU Meeting Reminder
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 89 09:10:48 PST
Date: Wed 1 Feb 89 09:07:52-PST
From: Sharon Hemenway <HEMENWAY@Score.Stanford.EDU>
Subject: Meeting Reminder
To: phd-adm@Score.Stanford.EDU
Reply-To: Hemenway@Score.Stanford.EDU
Message-ID: <12467231469.23.HEMENWAY@Score.Stanford.EDU>
Just a reminder of our meeting tomorrow, at 12 noon in MJH 252. Lunch
(sandwiches, etc.) will be provided.
An advance apology to those of you who have to come in from off-campus
but we are not going to be able to get the first sets out until Friday
afternoon. To have them ready by our meeting tomorrow would mean that
we would, in effect, lose two days worth of material which could make
many more folders "complete" (folders will only go out to be read when
they are complete). Right now, we have only about 180 complete
folders so every little bit helps. I'm sure that we would be able to
arrange an after-hours or Saturday pick-up point, if necessary.
See you all tomorrow...
Sharon
-------
∂01-Feb-89 1353 X3J13-mailer Fairfax information and registration form
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 1 Feb 89 13:51:58 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA01841g; Wed, 1 Feb 89 13:46:50 PST
Received: by challenger id AA07139g; Wed, 1 Feb 89 13:42:36 PST
Date: Wed, 1 Feb 89 13:42:36 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8902012142.AA07139@challenger>
To: x3j13@sail.stanford.edu
Subject: Fairfax information and registration form
**PLEASE NOTE DATE CHANGE:
In order to include Subcommittee meetings prior to the Committee meeting, the
Committee meeting start date has been moved from 3/27 to 3/28.
Please let me know ASAP if you are planning to attend and whether you'll be
staying at the Marriott. On Monday I have to confirm the number rooms we
need.
Mailings should be completed by March 15 to avoid the ``two week rule''.
While we will have access to a copier, participants are encouraged to bring
their copies of subcommittee reports to the meeting.
---jan---
X3J13/ISO Meeting
X3J13: 3/27/89 - 3/30/89
ISO: 3/31/89 - 4/1/89
Fairfax, VA
SUBCOMMITTEE MEETINGS:
DATE: 3/27
PLACE: CONTEL (building is now shared with Lockheed and is so marked)
COMMITTEE MEETING:
DATES: 3/28 - 3/30
TIME: 9:00 - 5:00
CITY: Fairfax
PLACE: CONTEL
ADDRESS: 12015 Lee Jackson Highway (Route 50)
Note: We will not have to be escorted by secutity on the first floor,
but we will have to sign out and in again if we leave the building.
(THANKS BOB, for talking to security!)
DIRECTIONS FROM HOTEL: Route 50 West => Fair Oaks Shopping Center ramp
Turn right once in the complex and follow the circle half way around,
turning right into the CONTEL Parking area.
REGISTRATION FEE: $50 Payable to: LUCID, Inc.
HOTEL ACCOMODATIONS:
HOTEL: Marriott Courtyard
ADDRESS: 11220 Lee Jackson Highway, Fairfax, VA 22030 (Route 50)
PHONE: 800/447-7472, 703/273-6161
DIRECTIONS from airport:
Dullus Access Road => first exit, Route 28, turn right, heading south
Route 28 => Route 50 (Lee Jackson Highway) turn left, east towards Washington
Drive 8 1/2 - 9 miles (past Fair Oaks Shopping Center, on right)
The hotel is on the left just after Route 66.
RATE: $72/night
MENTION: "X3J13" for rate
ISO MEETING:
DATES: 3/31 - 4/1
TIME: 9:00 - 5:00
CITY: Fairfax
PLACE: CONTEL
ADDRESS: 12015 Lee Jackson Highway (Route 50)
For further information contact:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
jlz@lucid.com
(415) 329-8400
!
X3J13 March 1989 Meeting Registration Form
Please include check for $50.00 payable to Lucid mail to:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
(415) 329-8400
jlz@lucid.com
Name: _____________________________________________________________
Institution: ______________________________________________________
Phone: ____________________________________________________________
Lunch 3/28: _________ yes _______ no
Lunch 3/29: _________ yes _______ no
Lunch 3/30: _________ yes _______ no
If Subcommitte Room is Needed:
Subcommittee Name? ___________________________
How many people will attend? __________
Meeting time? __________
Length of meeting? __________
∂01-Feb-89 1759 emma@csli.Stanford.EDU CSLI Calendar, February 2, 4:14
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 89 17:59:16 PST
Received: by csli.Stanford.EDU (4.0/inc-1.0)
id AA04588; Wed, 1 Feb 89 16:37:13 PST
Date: Wed, 1 Feb 89 16:37:13 PST
From: emma@csli.Stanford.EDU (Emma Pease)
Message-Id: <8902020037.AA04588@csli.Stanford.EDU>
To: friends@csli.Stanford.EDU
Subject: CSLI Calendar, February 2, 4:14
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
2 February 1989 Stanford Vol. 4, No. 14
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
LINGUISTICS DEPARTMENT COLLOQUIUM
The Mapping Between Phonological Categories and Phonetic Continua
Some Case Studies
Michel T. T. Jackson
Yale University
Friday, 3 February, 4:15
Cordura Conference Room
____________
LINGUISTICS DEPARTMENT COLLOQUIUM
The Expression of Arguments in Serial Verb Constructions
Mark Baker
McGill University
Tuesday, 7 February, 7:30
Cordura Conference Room
-----------
COMMONSENSE AND NONMONOTONIC REASONING SEMINAR
A Minimal Model Semantics with Default Priorities
Paul Morris
IntelliCorp
Monday, 6 February, 3:15pm
MJH 301
Existing default reasoning systems may be divided into minimality
based formalisms, such as circumscription, and those that depend on a
fixed point construction, like default logic. The fixed point schemes
have appeared to possess an advantage in allowing implicit
specification of arbitrary priorities among defaults. However, they
also have disadvantages, including a lack of cumulativity, and
difficulty in properly representing some situations where a mere
possibility of some contingency is sufficient to overcome a default.
We present a model minimization scheme that supports implicit
specification of priorities among defaults. The system enjoys
cumulativity (like other model preference systems), and gives more
satisfactory results in situations where a possibility overcomes a
default.
-----------
SYMBOLIC SYSTEMS FORUM
The Ecology of Computation
Bernard A. Huberman
Dynamics of Computation Group, Xerox PARC
Friday, 10 February, 3:15
Room 60:61G
A most advanced instance of concurrent computation is provided by
distributed processing in open systems that have no global controls.
These emerging heterogeneous networks are becoming self-regulating
entities, which in their behavior are very different from their
individual components. Their ability to remotely spawn processes in
other computers and servers of the system offers the possibility of
having a community of computational agents that, in their
interactions, are reminiscent of biological and social organizations.
This talk will give a perspective on computational ecologies, and
describe a theory of their behavior, which explicitly takes into
account incomplete knowledge and delayed information on the part of
its agents. When processes can choose among many possible strategies
while collaborating in the solution of computational tasks, the
dynamics leads to asymptotic regimes characterized by fixed points,
oscillations, and chaos. We will also describe Spawn, an ongoing
project that utilizes idle computational resources in a distributed
network of high-performance workstations. Finally, we will discuss
the possible existence of a universal law regulating the way in which
the benefit of cooperation is manifested in the system.
∂01-Feb-89 2146 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Thirteenth Columbia University Theory Day
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Feb 89 21:46:34 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA14905; Wed, 1 Feb 89 21:45:29 -0800
Message-Id: <8902020545.AA14905@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Wed, 1 Feb 89 21:37:22 PST
Received: by BYUADMIN (Mailer R2.01A) id 3446; Wed, 01 Feb 89 18:25:40 MST
Date: Wed, 1 Feb 89 19:23:59 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Zvi Galil <galil@CS.COLUMBIA.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Zvi Galil <galil@CS.COLUMBIA.EDU>
Subject: Thirteenth Columbia University Theory Day
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
THE 13TH THEORY DAY
at Columbia University
SPONSORED BY THE DEPARTMENT OF COMPUTER SCIENCE
FRIDAY, APRIL 14, 1989
10:00 PROFESSOR JEFFREY D. Ullman
Stanford University
EFFICIENT PROCESSING OF LOGIC PROGRAMS
11:00 DR. JON L. BENTLEY
A.T.& T. Bell Laboratories
HOW TO SOLVE A MILLION-CITY TRAVELLING SALESMAN PROBLEM
2:00 PROFESSOR LANE A. HEMACHANDRA
University of Rochester
BEYOND THE FALLEN HIERARCHIES
3:00 DR. ALOK AGGARWAL
IBM T.J. Watson Research Center
ON SEARCHING IN MULTIDIMENSIONAL MONOTONE ARRAYS
Coffee will be available at 9:30 am.
All lectures will be in the Kellogg Conference Center on the fifteenth
floor of the International Affairs Building, 118th Street and
Amsterdam Avenue.
The lectures are free and open to the public.
Call (212) 854-2736 for more information.
Theory Day is supported in part by a grant from the National Science
Foundation.
∂02-Feb-89 0859 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Minutes to 1/10 Faculty Meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Feb 89 08:59:00 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 2 Feb 89 08:55:05-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA26991; Thu, 2 Feb 89 08:56:11 -0800
Date: Thu, 2 Feb 1989 8:56:08 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, srstaff@score
Subject: Minutes to 1/10 Faculty Meeting
Message-Id: <CMM.0.87.602441768.chandler@polya.stanford.edu>
I apologize for a typo that appears on page 3 of the minutes to the 1/10
faculty meeting. Under the heading "Financial", this year's budget has been
set at $3,644,000.00, not $3,644.00. Please correct your copy. Thanks.
∂02-Feb-89 0927 TAJNAI@Score.Stanford.EDU program for the Forum Conference
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Feb 89 09:26:55 PST
Date: Thu 2 Feb 89 09:19:21-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: program for the Forum Conference
To: faculty@Score.Stanford.EDU, students@Score.Stanford.EDU,
ras@Score.Stanford.EDU, staff@Score.Stanford.EDU
Message-ID: <12467495704.21.TAJNAI@Score.Stanford.EDU>
I posted the pogram on the CSD Bulletin Board. If you want me to mail it
to you on-line, let me know. It is long, and I don't want to clutter your
personal mailbox.
Carolyn Tajnai
-------
∂02-Feb-89 1102 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu What Exit Seminar Series
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Feb 89 11:02:20 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA03902; Thu, 2 Feb 89 11:01:01 -0800
Message-Id: <8902021901.AA03902@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Thu, 2 Feb 89 10:41:30 PST
Received: by BYUADMIN (Mailer R2.01A) id 6251; Thu, 02 Feb 89 08:46:28 MST
Date: Thu, 2 Feb 89 09:30:43 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Joan Feigenbaum <jf@RESEARCH.ATT.COM>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Joan Feigenbaum <jf@RESEARCH.ATT.COM>
Subject: What Exit Seminar Series
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
DIMACS, the new NSF Science and Technology Center for
DIscrete MAth and Computer Science, is pleased to announce
THE WHAT EXIT SEMINAR SERIES.
Tentatively, we are planning to sponsor a series of
day-long seminars, each organized around a specific topic
in discrete math or theoretical computer science. The
participating institutions are Rutgers, Princeton, Bellcore,
and AT&T Bell Labs, and the location of the meetings will
rotate among these four.
This is a preliminary announcement of the first seminar.
Topic: Approximation Algorithms for NP-Complete Problems
Date: Friday, March 3, 1989
Place: Princeton
There will probably be three formal talks, a lunch, and an
informal problem session. More information, including
speakers, titles, abstracts, directions, etc., will follow
in future announcements. In the meantime, please mark your
calendars.
Joan Feigenbaum
jf@research.att.com
∂02-Feb-89 1121 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Conference on Math. Foundations of Prog. Semantics
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Feb 89 11:21:37 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA04995; Thu, 2 Feb 89 11:19:50 -0800
Message-Id: <8902021919.AA04995@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Thu, 2 Feb 89 10:57:43 PST
Received: by BYUADMIN (Mailer R2.01A) id 1620; Thu, 02 Feb 89 00:28:13 MST
Date: Wed, 1 Feb 89 23:33:05 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Dave Schmidt <SCHMIDT%KSUVAX1.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Dave Schmidt <SCHMIDT%KSUVAX1.BITNET@forsythe.stanford.edu>
Subject: Conference on Math. Foundations of Prog. Semantics
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
ADVANCE PROGRAM
5th Conference on the Mathematical Foundations of Programming Semantics
Tulane University
New Orleans, Louisiana
March 29-April 1, 1989
Wednesday, March 29
8:30am Registration
9:00 Invited Speaker: Samson Abramsky, Imperial College
10:10 Connections between a concrete and an abstract model of
concurrent systems, Eugene W. Stark, SUNY Stony Brook
10:50 break
11:10 A hierarchy of domains for real-time distributed computing,
G.M. Reed, Oxford Univ.
11:50 Factorizing proofs in timed CSP,
Jim Davies and Steve Schneider, Oxford Univ.
12:30pm lunch
2:00 Invited speaker: Luca Cardelli, Digital SRC
3:10 Inductively defined types in the calculus of constructions,
Frank Pfenning, Carnegie-Mellon Univ.
3:50 break
4:10 On some semantic issues in the reflective tower,
Karoline Malmkjaer, University of Copenhagen
4:50 Semantic models for total correctness and fairness,
Michael Main and David Black, Univ. of Colorado
5:30 end of program
5:45 reception
Thursday, March 30
9:00am Invited speaker: John Reynolds, Carnegie-Mellon Univ.
10:10 Equationally fully abstract models of PCF,
Allen Stoughton, Univ. of Sussex
10:50 break
11:10 Final semantics for languages of specifications,
Lawrence Moss, IBM Research, and Satish Thatte, Univ. of California,
San Diego
11:50 Does ``N+1 times'' prove more programs correct than ``N times''?
Ana Pasztor, Florida Intl. Univ.
12:30pm lunch
2:00 Invited speaker: Peter Johnstone, Cambridge Univ.
3:00 break
3:30 Organizers' session (short presentations of invited abstracts)
6:00 end of program
7:30 banquet
Friday, March 31
9:00am Termination, deadlock, and divergence,
L. Aceto and M. Hennessy, Univ. of Sussex
9:40 A category-theoretic semantics for unbounded indeterminacy,
Prakash Panangadan and James Russell, Cornell Univ.
10:20 break
10:40 Unbounded nondeterminism in CSP,
A.W. Roscoe, Oxford Univ.
11:20 The semantics of priority and fairness in Occam,
Geoff Barrett, Oxford Univ.
noon lunch
1:15pm Invited speaker: Robin Milner, Edinburgh Univ.
2:15 end of program
Saturday, April 1
9:00am Algebraic types in PER models,
J.M.E. Hyland, Cambridge Univ., E.P. Robinson, Queen's Univ.,
and G. Rosolini, Universita degli Studi
9:40 Pseudo-retract functors for local lattices and bifinite L-domains,
Elsa Gunter, Univ. of Pennsylvania
10:20 break
10:40 L-domains and lossless powerdomains,
Radhakrishnan Jagadeesan, Cornell Univ.
11:20 Invited speaker: Peter Freyd, Univ. of Pennsylvania
12:20 end of program
Local Information for Participants
The meetings will take place in the Lupin Theater of the Dixon Performing Arts
Center on the campus of Tulane University. Attendees can choose to stay at
the Avenue Plaza Hotel, which is a 15 minute ride by streetcar from the
University, or at a dormitory on the Tulane University campus.
The Avenue Plaza Hotel is located at 2111 St. Charles Avenue; registration
information is listed below. Transportation to the meeting is
provided by the St. Charles Streetcar line, which travels directly from the
hotel to the University. The fare is 60 cents, and exact change is required.
The meeting room for the conference is a ten minute walk from the Tulane street
car stop.
Dormitory accomodations are located on the Tulane University campus.
Registration information is listed below. The meeting room is about a ten
minute walk from the dormitories.
A map will be sent to those who register in advance.
The weather in New Orleans in late March is spring-like, with high temperatures
in the 60s or higher. Rain is a possibility.
Transportation from the airport to the hotel is available from the airport
limousine service or from taxis. The limousine service costs $7 per person and
runs virtually continuously. Taxis are always available, and the cost for
transportation to the hotel or the dormitory is about $18 for 4 people or less.
Since the limousine takes a rather long fixed route, stopping at major hotels
only, a taxi might be the preferred transportation for those staying at the
dormitory or for a group of three or more staying at the hotel.
In addition to the scientific program at the workshop, there are two planned
social events. A reception will be held on Wednesday afternoon, immediately
following the last talk of the day. A banquet will occur Thursday evening.
Spouses and friends are welcome; additional tickets for the banquet will be
available for purchase at the meeting. No organized excursions are planned,
but Friday afternoon and evening are left open for individual activities.
Please note that the University has no provisions for accepting credit cards,
so registrants should be prepared to pay registration fees by cash or check.
Lastly, reservations for the limousine service from the hotel to the airport
must be made at least 3 hours in advance of when one plans to leave the hotel.
The limo will take approximately 1 hour to reach the airport from the hotel.
Registration Form----------------------------------------------------
Conference on Mathematical Foundations of Programming Semantics
Name:
Address:
E-mail:
Telephone:
Registration fee (mark one; payment may be enclosed with this form or can be
made on the first day of the workshop) Note: registration fee includes price
of one banquet ticket.
__ Regular (payment made by March 10) $70
__ Regular (payment made after March 10) $80
__ Student $35
Extra banquet tickets (add $30 per ticket): ___
Make checks payable to: Conference on Mathematical Foundations
Please mail to:
Ms. Geralyn Caradona
Mathematics Department
Tulane University
New Orleans, LA 70118
Telephone (504) 865-5727
Accomodation Information-------------------------------------------
Avenue Plaza Hotel, 2111 St. Charles Ave., New Orleans, LA 70130
Telephone: 800-535-9575 or 504-566-1212.
Room Rates: 1 person $55/night
2 persons $55/night
3 persons $70/night
Contact the hotel directly to make reservations. Please mention that you are
attending the Mathematical Foundations Conference sponsored by the Mathematics
Department of Tulane University.
To make reservations for a dormitory room on the campus, contact the local
arrangements chairman, Dr. Boumediene Belkhouche, whose address and phone are
listed below. Since space in the dormitories is limited, contact him as soon
as possible.
Room Rates: 1 person $20/night (or $35/night for "luxury dorm room")
2 persons $25/night (or $45/night for "luxury dorm room")
For further information, contact the Local Arrangements Chairman
Dr. Boumediene Belkhouche
Computer Science Dept.
Tulane University
New Orleans, LA 70118
504-865-5840 bb@cs.tulane.edu
∂02-Feb-89 1307 X3J13-mailer Really about TYPEP failures: Comments on the Character proposal dated January 1, 1989
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 2 Feb 89 13:07:23 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03279g; Thu, 2 Feb 89 13:02:01 PST
Received: by bhopal id AA29703g; Thu, 2 Feb 89 13:04:21 PST
Date: Thu, 2 Feb 89 13:04:21 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8902022104.AA29703@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: Baggins@IBM.COM, CL-Characters@SAIL.STANFORD.EDU, X3J13@SAIL.STANFORD.EDU,
Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM,
KMP@STONY-BROOK.SCRC.Symbolics.COM,
Palter@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: David A. Moon's message of Tue, 31 Jan 89 16:53 EST <19890131215325.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Really about TYPEP failures: Comments on the Character proposal dated January 1, 1989
re: I'm afraid I don't understand your comment. What's inadequately
specified about SIMPLE-BASE-STRING?
Sorry, I wasn't clear enough here. The phrase used was "wishy-washy",
and it didn't mean that the specification was unclear or something;
rather, it called in question the enforcement of the specification. As
I understand it, it's entirely permissible for one implementation to
merge SIMPLE-BASE-STRING and SIMPLE-GENERAL-STRING into one type,
whereas another may make them type-disjoint.
This is a problem not specific to SIMPLE-BASE-STRING etc, but also applies
to any "wishy-washyness" about the disjointedness of types, where
there is good reason to believe that some implementations will truly
utilize that disjointnedness. Recall my comment about the situation
with the FLOAT datatype:
Contrast this with the situation regarding the type FLOAT. Although
there are many aspects of non-portability regarding the _use_ of
floating point numbers, there is no permitted variance in the definition
of the type FLOAT. It is never permissible, for example, for one
implementation to implement the FLOAT datatype as lists of integers,
and another to implement it as some low-level primitive datatype.
Thus if a user's "declaration" (CHECK-TYPE X FLOAT) fails in one
implementation, but works in another, it is not due to an inherent
weakness in the specification of the type FLOAT.
Suppose for the moment that one implementation merges the FLOAT and CONS
datatypes by implementing FLOATs as a list of three integers (such as the
the values returned by integer-decode-float), but another implementation
makes them disjoint as "primitive" types. At first blush, one might want
to dismiss this case as simply an "efficiency" concern for the second
implementation. But consider the problems for someone developing the
following program on the first implementation and delivering it on the
second:
(defun foo (x)
(if (typep x 'float)
(sin x)
(error "Must have a float")))
(foo (list 1 0 1)) ;; knowing that (float 1.0) is ...
This is a valid program in the first implementation, because the list
(1 0 1) is a valid FLOAT in that implementation. But when moving it to
the second implementation, you get a bug. Now, implementing FLOATs as
LISTs may look artificial, but this example exactly parallels one of the
more annoying porting problems that some 3600 users have when going into
virtually any of the stock hardare implementations. See footnote below.
Recall the recent cleanup proposal to "tighten up" the definition of
FIXNUM so that its use will more frequently be portable.
Recall also the recent cleanup issue to tighten the FUNCTION type so
that it is no longer ambiguous with SYMBOL.
Recall also the CLOS need to tighten up the disjointedness of the types
found on CLtL p.31 (along with others too); 88-002R, p.1-17.
Recall the trouble we've had with the ambiguity in the alternatives
for SHORT-FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT, and LONG-FLOAT.
Given this long history of misguided permissiveness, and our frequent
need to "tighten things up", don't you think it would a mistake to start
out with the types SIMPLE-BASE-STRING and SIMPLE-GENERAL-STRING ambiguous?
You also asked about how Lucid might implement open-coding of SGCHAR and
SBCHAR. This is immaterial. I only meant to say that *if* the character
proposal were to require (or suggest) that SIMPLE-STRING be a union of
two primitive types, we could "swallow" that (possible a little gulping
along the way). Dave Unietis of Lucid, who has been participating in the
Character subcommittees deliberations, will probably make a more detailed
commentary soon as to what we expect of the Character Proposal.
-- JonL --
Footnote:
Actually, the FLOATs-as-LISTs example is of more than passing interest,
because if you change the names appropriately, you will see exactly
the same problem that certain users have when porting code from the 3600
implementation to *any* stock hardware implementation that does serious
open-coding of AREF. Note that the only function I've mentioned is
TYPEP -- not hokey-pokey-adjust-array or whatever; that's why all the
thousands of lines of discussion about adjust-array etc on cl-cleanup are
not germane to the real problem. Focusing on adjust-array can, at best,
emasculate some of its mandated error checking; at worst, it can confuse
some would-be heros into thinking that the type disjointedness in question
is merely a matter of semantics that can cleared up by clever wording.
Make no mistake. The disjointedness is essential to the optimization
strategies of *all* the commercial stock hardware implementations
represented at the Hawaii meeting.
∂02-Feb-89 1613 @polya.Stanford.EDU:tah@linz MTC Seminar
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Feb 89 16:11:38 PST
Received: from [36.8.0.142] by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA25644; Thu, 2 Feb 89 16:08:55 -0800
Received: by linz.stanford.edu (5.59/25-eef) id AA01841; Thu, 2 Feb 89 16:02:24 PDT
Message-Id: <8902030002.AA01841@linz.stanford.edu>
To: lop@polya
Subject: MTC Seminar
Reply-To: tah@cs.stanford.edu
Date: 02 Feb 89 16:02:21 PST (Thu)
From: Tom Henzinger <tah@linz>
Friday, February 3, 12 noon, MJH 301:
I'm going to try to recreate Samson Abramsky's POPL tutorial talk on
concurrency from his slides.
The tutorial focuses on the semantics of labeled transition systems,
in which concurrency is reduced to nondeterminism (by interleaving).
A number of answers have been proposed in the literature to the
following fundamental question: when do two processes have the same
meaning? Abramsky unifies the analysis of process equivalences by
reducing them to equality on the observable behavior of processes:
p ~ q iff for all observable properties A,
p satisfies A precisely when q satisfies A.
Dependent on which primitive observations are admitted, this definition
yields (most of) the previously proposed equivalences on processes.
-- Tom.
∂02-Feb-89 1639 STAGER@Score.Stanford.EDU Preliminary Class Lists
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Feb 89 16:38:58 PST
Date: Thu 2 Feb 89 16:34:45-PST
From: Claire Stager <STAGER@Score.Stanford.EDU>
Subject: Preliminary Class Lists
To: faculty@Score.Stanford.EDU
Office: CS-TAC 29, 723-6094
Message-ID: <12467574965.43.STAGER@Score.Stanford.EDU>
Preliminary class lists have arrived and will be delivered to your mailboxes
tomorrow (Friday).
Claire
-------
∂02-Feb-89 1644 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Found: one cute lemma, doesn't answer to any name.
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Feb 89 16:44:41 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA28342; Thu, 2 Feb 89 16:43:07 -0800
Message-Id: <8902030043.AA28342@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Thu, 2 Feb 89 16:31:33 PST
Received: by BYUADMIN (Mailer R2.01A) id 7296; Thu, 02 Feb 89 17:30:10 MST
Date: Thu, 2 Feb 89 16:56:51 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Martin Tompa <TOMPA%YKTVMX.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Martin Tompa <TOMPA%YKTVMX.BITNET@forsythe.stanford.edu>
Subject: Found: one cute lemma, doesn't answer to any name.
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
In writing a paper, we came upon the combinatorial lemma given below.
We have been told that this lemma appeared somewhere previously, and
would like to include the appropriate citation. If you have lost this
lemma or have information on the whereabouts of its owner, please send a
note to tompa@ibm.com (or tompa@yktvmx on bitnet).
Lemma:
For k > 0, let B be a 2**k by k matrix whose rows are the 2**k distinct
elements of {0,1}**k. Let M be an r by n Boolean matrix with distinct
rows, and not containing as a submatrix any matrix whose rows are a
permutation of the rows of B. Then
r is at most the sum, as j goes from 0 to k-1, of n choose j.
∂02-Feb-89 1729 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu NIPS CALL FOR PAPERS
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Feb 89 17:29:01 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA01009; Thu, 2 Feb 89 17:28:01 -0800
Message-Id: <8902030128.AA01009@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Thu, 2 Feb 89 17:26:58 PST
Received: by BYUADMIN (Mailer R2.01A) id 7706; Thu, 02 Feb 89 17:42:42 MST
Date: Thu, 2 Feb 89 16:59:14 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Stephen J Hanson <jose@TRACTATUS.BELLCORE.COM>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Stephen J Hanson <jose@TRACTATUS.BELLCORE.COM>
Subject: NIPS CALL FOR PAPERS
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
CALL FOR PAPERS
IEEE Conference on
Neural Information Processing Systems
- Natural and Synthetic -
Monday, November 27 -- Thursday November 30, 1989
Denver, Colorado
This is the third meeting of a high quality, relatively small,
inter-disciplinary conference which brings together
neuroscientists, engineers, computer scientists, cognitive
scientists, physicists, and mathematicians interested in all
aspects of neural processing and computation. Several days of
focussed workshops will follow at a nearby ski area. Major
categories and examples of subcategories for papers are the
following:
1. Neuroscience: Neurobiological models of development, cellular
information processing, synaptic function, learning, and memory.
Studies and analyses of neurobiological systems and development
of neurophysiological recording tools.
2. Architecture Design: Design and evaluation of net
architectures to perform cognitive or behavioral functions and to
implement conventional algorithms. Data representation; static
networks and dynamic networks that can process or generate
pattern sequences.
3. Learning Theory Models of learning; training paradigms for
static and dynamic networks; analysis of capability,
generalization, complexity, and scaling.
4. Applications: Applications to signal processing, vision,
speech, motor control, robotics, knowledge representation,
cognitive modelling and adaptive systems.
5. Implementation and Simulation: VLSI or optical implementations
of hardware neural nets. Practical issues for simulations and
simulation tools.
Technical Program: Plenary, contributed, and poster sessions will
be held. There will be no parallel sessions. The full text of
presented papers will be published.
Submission Procedures: Original research contributions are
solicited, and will be refereed by experts in the respective
disciplines. Authors should submit four copies of a 1000-word
(or less) summary and four copies of a single-page 50-100 word
abstract clearly stating their results by May 30, 1989. Indicate
preference for oral or poster presentation and specify which of
the above five broad categories and, if appropriate, sub-
categories (for example, Learning Theory: Complexity, or
Applications: Speech) best applies to your paper. Indicate
presentation preference and category information at the bottom of
each abstract page and after each summary. Failure to do so will
delay processing of your submission. Mail submissions to Kathy
Hibbard, NIPS89 Local Committee, Engineering Center, Campus Box
425, Boulder, CO, 80309-0425.
DEADLINE FOR SUMMARIES ABSTRACTS IS MAY 30, 1989
∂02-Feb-89 1815 snoeyink@polya.Stanford.EDU Bats Speakers and Abstracts
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Feb 89 18:15:17 PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA03809; Thu, 2 Feb 89 18:13:59 -0800
Date: Thu, 2 Feb 89 18:13:59 -0800
From: Jack Snoeyink <snoeyink@polya.Stanford.EDU>
Message-Id: <8902030213.AA03809@polya.Stanford.EDU>
To: aflb-local@polya.Stanford.EDU
Subject: Bats Speakers and Abstracts
Bats is Friday, Feb 10 at Berkeley.
The schedule is as follows:
10:10 Dorit Hochbaum (Berkeley): The Complexity of Integer Nonlinear
Optimization over Linear Polytopes
11:10 Peter Gacs (Boston University and IBM Almaden Research Center)
Self-correcting and self-organizing cellular arrays
12:10 Ashok Subramanian (Stanford) The Complexity of Circuit
Value and Network Stability
1:10 Seffi Naor (Stabford) Maximum Flow in Networks with Many
Sources and Sinks
---------------------------------------------------------------------
The complexity of integer nonlinear optimization over linear polytopes.
Dorit Hochbaum
University of California, Berkeley
We prove that concave separable objective optimization problems on
linear polytopes with polynomially bounded subdeterminants of the
constraint matrix can be solved in polynomial time. The integer
version of this problem is also solvable in polynomial time in the
same parameters, if the corresponding integer linear problem is
solvable in polynomial time (the algorithm will require a single
call to a routine that solves a linear integer problem on the same
polytope).
An important corollary is that nonlinear integer optimization with
concave (convex) separable objective function over a polytope
defined by a totally unimodular constraint matrix is a polynomial
problem. The running time of the algorithm is polynomial but not
strongly polyomial. It depends on the logarithm of the right hand
side vector in the constraint set. We provide a lower bound proof
to show that this problem cannot be solved in strongly polynomial
time. This is in contrast to the linear integer optimization over
a totally unimodular constraint matrix which is solvable in strongly
polynomial time (Tardos 86).
A special case of this problem is the integer nonlinear resource
allocation problem. We provide a algorithm for this problem which
is best possible for a certain class of such problems in that its
running time is equal to the lower bound on this problem's complexity.
For the quadratic separable case of this problem we describe a
strongly polynomial algorithm.
---------------------------------------------------------------------
Self-correcting and self-organizing cellular arrays
Peter Gacs
Boston University and IBM Almaden Research Center
A computer in the future may be just a large crystal of smart
molecules grown artificially. The components work according to
a probabilistic transition rule in continuous time. All
non-uniformity in structure is created by the machine itself,
responding to the demands of the computation to be carried out. One
can also arrive to the problems of reliability and self-organization
presented by the above requirement starting from an interest in the
origins of life. A soup of chemical ingredients, in a noisy
environment, started organizing itself and became able to carry out
larger and larger computations reliably. No hypotheses will be
stated on how this actually happened in nature, nor practical designs
offered of reliable computing molecules. But an example of a
transition rule will be given that provably satisfies all the
requirements. Its organizational principles are therefore worth
studying both for the design of future reliable computers and for
ideas on understanding biological evolution.
The new construction builds on earlier experience with reliable
cellular automata. Self-organization and continuous time are new, as
well as the primitive concepts allowing a modular design that is
easier to analyze.
---------------------------------------------------------------------------
The Complexity of Circuit Value and Network Stability
Ashok Subramanian
The Circuit Value problem asks for the output of an acyclic network of
boolean gates, given its inputs. The Network Stability problem asks if a
given network, possibly cyclic, of boolean gates has stable configurations.
(A stable configuration of a network is an assignment of truth values to
the edges of the network that respects all the gate equations.) We study
the complexity of these problems as a function of the kinds of gates
allowed in the network. In our model, gates may have many outputs, but no
fanout is allowed outside gates. This model permits the study of the effect
of fanout on the complexity of the above problems. The results: If the
gates do not `preserve adjacency' (in other words, if they can `make
copies' of their inputs), the problems are usually complete for a standard
complexity class like P or NP. But if the gates preserve adjacency, we get
new classes of problems, classes that lie between Logspace and P, but seem
incomparable to the parallel complexity class NC.
We identify an interesting subset of the adjacency-preserving gates, those
that lack `scatter'. Intuitively, a gate lacks scatter if it is never
possible for a small number of inputs to influence a larger number of
outputs. We give a linear time algorithm for the network stability problem
over scatter-free networks, and an O*(sqrt(n)) time algorithm for
scatter-free circuit value.
One of the most fundamental of the new classes is the class CC. Problems
complete for CC include Comparator Circuit Value, Lexicographically-first
Maximal Matching, and problems related to Stable Matching. Our approach to
Stable Matching is to regard it as a network stability problem. This
approach yields fresh insights and new algorithms.
(This work represents work done towards my doctoral dissertation, under the
direction of Ernst Mayr.)
---------------------------------------------------------------------------
Seffi Naor
Stanford University
The problem of maximum flow in planar graphs was always investigated
under the assumption that there is only one source and one sink.
We are going to consider the case where there are many sources and sinks in
a directed planar graph.
An algorithm for the case when the demands of the sources
and sinks are known will be presented which
can be implemented in parallel in $O(\log ↑2n)$ time
using $O(n↑{1.5})$ processors, and in sequential $O(n↑{1.5})$ time.
It uses a novel idea of redirecting
the flow back from the sinks to the sources and then reducing the problem to
that of computing a circulation.
If the demands are not known, we will show how to compute the max flow
in the special case when the sources and sinks are on
the same face.
This result has two applications:
it places the problem of computing a perfect matching in a planar
bipartite graph in NC; it improves a previous parallel
algorithm for the case of a single source, single sink in a planar
directed (and undirected) graph,
both in terms of time complexity and processor bound,
and in its simple presentation.
This is joint work with Gary Miller.
∂02-Feb-89 1826 snoeyink@polya.Stanford.EDU Going to BATS
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Feb 89 18:26:04 PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA04263; Thu, 2 Feb 89 18:24:48 -0800
Date: Thu, 2 Feb 89 18:24:48 -0800
From: Jack Snoeyink <snoeyink@polya.Stanford.EDU>
Message-Id: <8902030224.AA04263@polya.Stanford.EDU>
To: aflb-local@polya.Stanford.EDU
Subject: Going to BATS
In order to get parking permits for drivers and lunches for everyone,
I'd like to know who is going to BATS at Berkeley on Friday the 10th.
If you want to go, please tell me:
if you will be there for lunch,
if you will/can drive, and
what talks you want to attend.
Thanks,
Jack
--------------------------------
DRIVING INSTRUCTIONS TO BATS:
BATS is on Friday, February 10. All talks are in Sibley Auditorium,
located in the Bechtel building just north of Evans Hall on the
Berkeley campus. Lunch is served in 120AB Bechtel one floor below Sibley.
To get to the university from Highway 80, take the University Avenue
exit, and continue until the road ends. Turn left onto Oxford, continue north
to the next light, and turn right on Hearst. Continue on Hearst (which forms
the northern border of campus) until you can make a right turn on Gayley
(eastern border of campus). The first possible right off Gayley leads
into campus at the Mining Circle, near Evans Hall. There is a
kiosk at the entrance at which you can pick up your parking stickers
(mention BATS), and get directions on where to park. My understanding
is that with a parking sticker you have a high probability of finding
a place to park on campus.
To get to the university from Highway 13, Highway 13 from the south
turns naturally into Ashby heading west. Take College Avenue north
(I think it's the second light) to Dwight Way; go east on Dwight
to Piedmont Avenue (where Dwight becomes two-way), and go north on Piedmont.
Piedmont will become Gayley, and you will see the left turn for the East
Gate opposite the Greek Theatre.
To take BART, get off at the Berkeley BART station. Across from the BART
station on the northeast corner of Center and Shattuck you can take the
free Humphrey Go-BART shuttle to the front of Evans Hall, the computer science
building. The Bechtel building is the building just north of Evans.
The walk from the BART station to Bechtel takes 10-15 minutes, gently uphill.
∂02-Feb-89 2125 hoffman@csli.Stanford.EDU This Friday's (the 3rd) Symbolic Systems Forum
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Feb 89 21:25:40 PST
Received: by csli.Stanford.EDU (4.0/inc-1.0)
id AA16173; Thu, 2 Feb 89 21:10:00 PST
Date: Thu 2 Feb 89 21:09:59-PST
From: Reid Hoffman <HOFFMAN@CSLI.Stanford.EDU>
Subject: This Friday's (the 3rd) Symbolic Systems Forum
To: FriendsAtLarge@csli.Stanford.EDU
Message-Id: <602485799.0.HOFFMAN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
This week's Symbolic Systems Forum will be
Structure Yes, Symbols No
a talk by
Professor Jerome A. Feldman
Institute for Cognitive Science,
Berkeley, CA
Abstract:
Computer Science, Artificial Intelligence and many related fields have
followed symbol-processing paradigms almost without exception. Recent
work has suggested alternative views of intelligent activity based on
connectionist (or PDP or `neural') networks. This talk will discuss a
``Structured" connectionist approach which attempts to capture the
best features of symbollic and neural-style computation. After some
preliminaries, the talk will focus on a connectionist model of visual
recognition which is claimed to be (the only model) consistent with
the relevant biological, behavioral and computational findings.
Finally, we will try to indicate what this model suggests about how
intelligence as realized is animals and artifacts.
Time: Friday, Feb. 3rd, 3:15
Place: Building 60, Room 60-61G
The talk will be open to the general public. To join the mailing list,
send mail to hoffman@csli
-------
∂02-Feb-89 2345 LOGMTC-mailer Seminar in Logic
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Feb 89 23:45:06 PST
Received: by csli.Stanford.EDU (4.0/inc-1.0)
id AA18555; Thu, 2 Feb 89 23:43:21 PST
Date: Thu 2 Feb 89 23:43:20-PST
From: Sol Feferman <SF@CSLI.Stanford.EDU>
Subject: Seminar in Logic
To: Logic@csli.Stanford.EDU
Message-Id: <602495000.0.SF@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
Speaker: Prof. Michael Beeson, Mathematics, San Jose State University
Title: Applications of Gentzen's proof theory to automated deduction.
Time: Tuesday, Feb. 7, 4:15-5:30 PM
Place: Room 381-T, Math Corner, Stanford
Abstract: An algorithm for (attempting to) construct a proof of a
given theorem from given axioms will be explained. The algorithm
constructs a proof in a Gentzen sequent calculus. When restricted to
Horn clauses, it coincides with Prolog's algorithm. Completeness of
the algorithm can be proved using Gentzen's cut-elimination and a
"permutation lemma" of Kleene. Examples will be given of the practical
efficiency of the algorithm on some non-Prolog examples.
* * * *
The following week, Prof. I. Katznelson will begin the first of two
talks, on Monday Feb.13, same time, but in Room 383-N (3d floor lounge).
The second of his talks will be on Tuesday FEb. 21, usual time and place.
S. Feferman
-------
∂03-Feb-89 0824 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Next Tuesday's Faculty Lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Feb 89 08:23:54 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 3 Feb 89 08:20:45-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA23029; Fri, 3 Feb 89 08:21:49 -0800
Date: Fri, 3 Feb 1989 8:21:47 PST
Sender: "Joyce R. Chandler" <chandler@polya.stanford.edu>
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, bureaucrats@score, staff-rep@score
Cc: RS.AJB@forsythe, CR.RLB@forsythe, HK.PLD@forsythe, LEVINTHAL@sierra
Subject: Next Tuesday's Faculty Lunch
Message-Id: <CMM.0.87.602526107.chandler@polya.stanford.edu>
Our guests at next Tuesday's faculty lunch (2/7 at 12:15 in Margaret Jacks
Hall conference room 146) will be Art Bienenstock, Bob Byer, Pat Devaney and
Elliot Levinthal. The topic of discussion will be the proposal to tax gifts.
Don't forget to mark your calendars!
P.S. to our guests: Our faculty lunches are very informal.....sandwiches,
salads and beverages are provided.
∂03-Feb-89 0840 HEMENWAY@Score.Stanford.EDU Round 1
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Feb 89 08:40:43 PST
Date: Fri 3 Feb 89 08:37:52-PST
From: Sharon Hemenway <HEMENWAY@Score.Stanford.EDU>
Subject: Round 1
To: phd-adm@Score.Stanford.EDU
Message-ID: <12467750295.19.HEMENWAY@Score.Stanford.EDU>
To reiterate what we discussed at yesterday's meeting, the schedule
of readings for Round 1 follows:
Available (after 4:00) Due (by 10:00)
_______________________ _________________
Batch 1 Friday, Feb. 3 Monday, Feb. 6
Batch 2 Monday, Feb. 6 Thursday, Feb. 9
Batch 3 Thursday, Feb. 9 Monday, Feb. 13
Batch 4 Monday, Feb. 13 Thursday, Feb. 16
I will put a box outside of my office door where you may either pick
up or drop off your folders, if outside of normal office hours.
One thing we did not mention at yesterday's meeting is the actual
range of ratings. You may assign any value between 1 and 5, to two
decimal places. For those of you who missed the beginning of the
meeting, I repeat my suggestion that writing comments (to yourself)
on the rating sheets can be very helpful at the Round 1 and Round 2
meetings where we will hand back your rating sheets.
Please, if you notice any errors on the rating sheets (incorrect
GPA, GRE scores, school, etc.) let us know and we will correct it
for the next round.
Many thanks for your help.
Sharon
-------
∂03-Feb-89 0907 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu [jadams@note.nsf.gov: Educational Supplements to CISE-Research Grants]
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Feb 89 09:06:57 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 3 Feb 89 08:54:22-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA05910; Fri, 3 Feb 89 08:53:59 PDT
Date: Fri, 3 Feb 89 08:53:59 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8902031653.AA05910@Tenaya.stanford.edu>
To: faculty@score
Subject: [jadams@note.nsf.gov: Educational Supplements to CISE-Research Grants]
fyi:
-----
Return-Path: <@Tenaya.stanford.edu,@Score.Stanford.EDU:jadams@note.nsf.gov>
To: cise.news@note.nsf.gov
Cc: hhedges@note.nsf.gov, bbarnes@note.nsf.gov
Subject: Educational Supplements to CISE-Research Grants
Date: Fri, 03 Feb 89 10:00:24 -0500
From: "J. Mack Adams" <jadams@note.nsf.gov>
Dear Colleague:
As part of an expanding effort to encourage innovation and
significant new efforts in undergraduate education, the Computer
and Information Science and Engineering (CISE) Directorate
announces the availability in FY 1989 (this fiscal year) of
Educational Supplements to CISE.Research grants. A major goal of
this experimental program is to establish closer links between
CISE.supported research and undergraduate education and assist in
accelerating the transfer of research results into the
classrooms.
Guidelines for this Educational Supplement program are as follows:
1. Eligible Proposers: Any Principal or Co.Principal Investigator
on an active NSF award from a program in the CISE Directorate.
2. Kinds of Projects: Proposal Supplements for innovative and
creative educational activities are solicited. Research
experiences are excluded. Examples of projects might include:
special interactive software for student use to provide insight
about the goals and results of the research project, graphic
visualizations of significant research results, research
implementations of leading-edge technology, use of electronic
networks in education, etc. Please note, these are only possible
examples. Your creativity is encouraged!
3. Size and Duration of Awards: Supplements will range from
$4,000 to $20,000 and the basic award can be extended, if
necessary and appropriate.
4. Cost Sharing: Since these projects are closely related to
the educational activities of the institution, significant cost
sharing by the grantee is expected.
5. Procedures for Application: Submit, through your Research
Administration Office, a request, with budget, for a supplement
to an existing research award. The request should be in the
form of a two to four page document describing what is proposed
to be done, how it relates to the research portion of the award,
what significance it will have, if funded, and ideas for
making the results available elsewhere.
6. Action at the NSF: The proposals will be reviewed promptly and
announcement of awards are expected to be made within six weeks
of submission.
If you have any questions concerning these educational
supplements, please contact the Program Director for your award.
Sincerely,
William A. Wulf
Assistant Director
∂03-Feb-89 1130 HEMENWAY@Score.Stanford.EDU GRE Analytical Scores
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Feb 89 11:30:22 PST
Date: Fri 3 Feb 89 11:28:02-PST
From: Sharon Hemenway <HEMENWAY@Score.Stanford.EDU>
Subject: GRE Analytical Scores
To: phd-adm@Score.Stanford.EDU
Message-ID: <12467781275.19.HEMENWAY@Score.Stanford.EDU>
I have just noticed that, contrary to my expectations, the scores from
the GRE Analytical section did NOT print out on the rating sheets for
Batch 1. I apologize for this and will have it corrected for the
Batch 2 rating sheets. Meanwhile, you can find each person's full
GRE scores stapled to the front inside of the folder.
Sharon
-------
∂03-Feb-89 2333 X3J13-mailer Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 Feb 89 23:33:32 PST
Received: from Semillon.ms by ArpaGateway.ms ; 03 FEB 89 23:31:31 PST
Date: 3 Feb 89 23:31 PST
From: masinter.pa@Xerox.COM
To: X3J13@sail.stanford.edu
Subject: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES (Version 3)
Line-fold: NO
Message-ID: <890203-233131-2862@Xerox>
This proposal was distributed and passed at the January X3J13 meeting.
Since it had not been emailed before, I am doing so now.
!
Status: Passed, Jan 89 X3J13
Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
References: Array type specifiers, pp. 45-46
Related issues: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS, DECLARE-TYPE-FREE,
SYMBOL-MACROLET-DECLARE
Category: CHANGE
Edit history: Version 1, 7-Oct-88, Pierson
Version 2, 13-Jan-89, Pierson (Moon and JonL comments)
Version 3, 13-Jan-89, Pierson (Pitman comments)
Problem description:
In principle, array type specifiers could be used both for declaring
the storage format of the array and for implicitly declaring the types
of the elements held by those arrays. Unfortunately, the current
definition of the meaning of array type specifiers does not explicitly
specify that the latter use of these declarations is legitimate.
Proposal (DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES:RESTRICTIVE):
Within the lexical scope of an array type declaration, all references
to array elements are assumed to satisfy the exact declared element
type. It is an error if this is ever violated. A compiler may treat
the code within the scope of the array type declaration as if each
access of an array element was surrounded by an appropriate THE form.
Examples:
(DEFVAR *ONE-ARRAY* (MAKE-ARRAY 10 :ELEMENT-TYPE '(SIGNED-BYTE 5)))
(DEFVAR *ANOTHER-ARRAY* (MAKE-ARRAY 10 :ELEMENT-TYPE '(SIGNED-BYTE 8)))
(DEFUN FROB (AN-ARRAY)
(DECLARE (TYPE (ARRAY (SIGNED-BYTE 5) 1) AN-ARRAY))
(SETF (AREF AN-ARRAY 1) 31) ; OK
(SETF (AREF AN-ARRAY 2) 127) ; Should signal an error
(SETF (AREF AN-ARRAY 3) (* 2 (AREF AN-ARRAY 3))) ; Run-time decision needed
(LET ((FOO 0))
(DECLARE (TYPE (SIGNED-BYTE 5) FOO))
(SETF FOO (AREF AN-ARRAY 0)))) ; Declared to be safe
(FROB *ONE-ARRAY*) ; Legal call, should signal an error
(FROM *ANOTHER-ARRAY*) ; Is probably an undetectable error
Note that the above definition of FROB is equivalent to:
(DEFUN FROB (AN-ARRAY)
(DECLARE (TYPE (ARRAY (SIGNED-BYTE 5) 1) AN-ARRAY))
(SETF (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 1) 31))
(SETF (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 2) 127))
(SETF (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 3))
(* 2 (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 3))))
(LET ((FOO 0))
(DECLARE (TYPE (SIGNED-BYTE 5) FOO))
(SETF FOO (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 0)))))
Given an implementation in which fixnums are 29 bits but fixnum arrays
are upgraded to signed 32-bit arrays, the following should be compiled
with all fixnum arithmetic:
(DEFUN BUMP-COUNTERS (COUNTERS)
(DECLARE (TYPE (ARRAY FIXNUM *) BUMP-COUNTERS))
(DOTIMES (I (LENGTH COUNTERS))
(INCF (AREF COUNTERS I))))
Test Cases:
TBS
Rationale:
This mandates a useful and commonly expected behavior. It complements
proposal ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS, which deals with array
type specifiers as they refer to arrays as a whole.
This proposal is consistent with SYMBOL-MACROLET-DECLARE:ALLOW and
DECLARATION-SCOPE:LEXICAL.
Current practice:
???
Cost to Implementors:
TBS
Cost to Users:
Probably none; while this is technically a change, code that declares
an array to contain one thing and depends on it containing something
else is blatantly buggy.
Cost of non-adoption:
Users will continue to expect declaration syntax to be more useful
than it really is.
Performance impact:
None.
Benefits:
Array type declarations will behave in a more useful and intuitive way.
Aesthetics:
Improved because the meaning of type declarations will coincide more
clearly with their appearance.
Discussion:
Pierson and Pitman support this proposal.
∂05-Feb-89 1020 X3J13-mailer Fairfax and Hotel badness
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 5 Feb 89 10:20:11 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa02852; 5 Feb 89 15:45 GMT
Date: Sun, 5 Feb 89 16:02:41 GMT
Message-Id: <13804.8902051602@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Fairfax and Hotel badness
To: Jan Zubkoff <@sail.stanford.edu:jlz@lucid.com>, x3j13@sail.stanford.edu
In-Reply-To: Jan Zubkoff's message of Wed, 1 Feb 89 13:42:36 PST
> Please let me know ASAP if you are planning to attend and whether you'll be
> staying at the Marriott. On Monday I have to confirm the number rooms we
> need.
I am planning to attend (both X3J13 and ISO) and to stay at the Marriott.
However, some people were saying that some hotel used for the last
Farifax meeting had been undesirable. Was that the Marriott, or was
the Marriott OK?
Is there any way to get around this area without a car?
∂05-Feb-89 1104 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu [fuller@sierra.STANFORD.EDU: Grants of HP equipment]
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Feb 89 11:04:06 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Sun 5 Feb 89 11:00:13-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA07298; Sun, 5 Feb 89 10:59:44 PDT
Date: Sun, 5 Feb 89 10:59:44 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8902051859.AA07298@Tenaya.stanford.edu>
To: faculty@score
Subject: [fuller@sierra.STANFORD.EDU: Grants of HP equipment]
fyi:
----
Return-Path: <@Tenaya.stanford.edu:fuller@sierra.STANFORD.EDU>
From: fuller@sierra.STANFORD.EDU (Dwain N. Fullerton)
Date: Tue, 31 Jan 1989 17:53:07 PST
To: Goodman@sierra.STANFORD.EDU, Nilsson@tenaya, hughes@sierra.STANFORD.EDU,
hagstrom@sierra.STANFORD.EDU
Cc: ct.hpo@forsythe, ct.jfk@forsythe, ct.ljl@forsythe,
fuller@sierra.STANFORD.EDU, allen_edwards%hp0400@hplabs.hp.com
Subject: Grants of HP equipment
Gents,
At lunch today Allen Edwards, HP's R&D Section Manager at the Stanford
Park Division, asked if there were some ideas for uses for HP instruments
and equipment under the company's special grants category. This means that
in general the equipnment should have a reasonably high visibility and be
used by as many individuals or affect as many individuals as possible. A
student lab, curriculum development, uses generally in that direction would
be possible. Note that the uses don't have to be exclusively for these
purposes, as long as there is some element in the ultimate use. If you have
some ideas, Edwards would be glad to offer advice and help with the proposal,
as he did with Dan Weise and a grant of Bobcat workstations. If you'd like
to get in touch with Edwards directly, his em address is
allen_edwards%hp0400@hplabs.hp.com
Note that if you send him an em, be sure to include your complete
return address in the text of the message, because HP's internal system strips
off the headers.
Best,
Dwain (fuller@sierra.stanford.edu)
∂05-Feb-89 2223 hoffman@csli.Stanford.EDU The Symbolic Systems Forum, Feb. 10th
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Feb 89 22:23:51 PST
Received: by csli.Stanford.EDU (4.0/inc-1.0)
id AA17548; Sun, 5 Feb 89 22:17:10 PST
Date: Sun 5 Feb 89 22:17:09-PST
From: Reid Hoffman <HOFFMAN@CSLI.Stanford.EDU>
Subject: The Symbolic Systems Forum, Feb. 10th
To: GeneralForumAnnouncement@csli.Stanford.EDU
Message-Id: <602749029.0.HOFFMAN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
The Symbolic Systems Forum presents
Professor Bernardo Huberman
Dynamics of Computation Group, Xerox PARC
Stanford Physics
on
The Ecology of Computation
Abstract:
A most advanced instance of concurrent computation is provided by
distributed processing in open systems which have no global controls. These
emerging heterogeneous networks are becoming self-regulating entities which
in their behavior are very different from their individual components.
Their ability to remotely spawn processes in other computers and servers of
the system offers the possibility of having a community of computational
agents which, in their interactions, are reminiscent of biological and
social organizations.
This talk will give a perspective on computational ecologies, and describe
a theory of their behavior which explicitly takes into account incomplete
knowledge and delayed information on the part of its agents. When processes
can choose among many possible strategies while collaborating in the
solution of computational tasks, the dynamics leads to asymptotic regimes
characterized by fixed points, oscillations and chaos. We will also
describe Spawn, an ongoing project which utilizes idle computational
resources in a distributed network of high-performance workstations.
Finally, we will discuss the possible existence of a universal law
regulating the way in which the benefit of cooperation is manifested in the
system.
The time: 3:15
The date: Feb. 10th
The place: room 61g, building 60
The talk is open to the general public. Refreshments will be served.
-------
∂06-Feb-89 0008 misha@polya.Stanford.EDU Next AFLB
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Feb 89 00:07:58 PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA07449; Mon, 6 Feb 89 00:04:52 -0800
Date: Mon, 6 Feb 89 00:04:52 -0800
From: Michael Kharitonov <misha@polya.Stanford.EDU>
Message-Id: <8902060804.AA07449@polya.Stanford.EDU>
To: aflb-all@polya.Stanford.EDU
Subject: Next AFLB
The next AFLB will be on Tuesday, Feb 7, at 4:15 in room 352.
Dr. A. Razborov from the Steklov Institute in Moscow will
speak.
ON THE METHOD OF APPROXIMATIONS
The talk will be devoted to a recent paper of the speaker
submitted to the STOC conference. In this paper the question
as to how the method of approximations could be useful for obtaining
lower bounds of the circuit size of Boolean functions is formalized
and studied.
----------------------------------------------------------------------
Dr. Razborov will also give a survey talk on circuit complexity
at the special session of cs366 (Lower Bounds) on Monday at 3:15.
∂06-Feb-89 0921 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Tomorrow's Faculty Lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Feb 89 09:21:12 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 6 Feb 89 09:17:40-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA15256; Mon, 6 Feb 89 09:18:23 -0800
Date: Mon, 6 Feb 1989 9:18:10 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, bureaucrats@score, staff-rep@score
Subject: Tomorrow's Faculty Lunch
Message-Id: <CMM.0.87.602788690.chandler@polya.stanford.edu>
The discussion - Proposal to tax gifts
The time - 12:15 2/7
The place - MJH-146
See you there!
∂06-Feb-89 1854 snoeyink@polya.Stanford.EDU Bats Speakers and Abstracts
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Feb 89 18:54:49 PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA03809; Thu, 2 Feb 89 18:13:59 -0800
Date: Thu, 2 Feb 89 18:13:59 -0800
From: Jack Snoeyink <snoeyink@polya.Stanford.EDU>
Message-Id: <8902030213.AA03809@polya.Stanford.EDU>
To: aflb-local@polya.Stanford.EDU
Subject: Bats Speakers and Abstracts
Bats is Friday, Feb 10 at Berkeley.
The schedule is as follows:
10:10 Dorit Hochbaum (Berkeley): The Complexity of Integer Nonlinear
Optimization over Linear Polytopes
11:10 Peter Gacs (Boston University and IBM Almaden Research Center)
Self-correcting and self-organizing cellular arrays
12:10 Ashok Subramanian (Stanford) The Complexity of Circuit
Value and Network Stability
1:10 Seffi Naor (Stabford) Maximum Flow in Networks with Many
Sources and Sinks
---------------------------------------------------------------------
The complexity of integer nonlinear optimization over linear polytopes.
Dorit Hochbaum
University of California, Berkeley
We prove that concave separable objective optimization problems on
linear polytopes with polynomially bounded subdeterminants of the
constraint matrix can be solved in polynomial time. The integer
version of this problem is also solvable in polynomial time in the
same parameters, if the corresponding integer linear problem is
solvable in polynomial time (the algorithm will require a single
call to a routine that solves a linear integer problem on the same
polytope).
An important corollary is that nonlinear integer optimization with
concave (convex) separable objective function over a polytope
defined by a totally unimodular constraint matrix is a polynomial
problem. The running time of the algorithm is polynomial but not
strongly polyomial. It depends on the logarithm of the right hand
side vector in the constraint set. We provide a lower bound proof
to show that this problem cannot be solved in strongly polynomial
time. This is in contrast to the linear integer optimization over
a totally unimodular constraint matrix which is solvable in strongly
polynomial time (Tardos 86).
A special case of this problem is the integer nonlinear resource
allocation problem. We provide a algorithm for this problem which
is best possible for a certain class of such problems in that its
running time is equal to the lower bound on this problem's complexity.
For the quadratic separable case of this problem we describe a
strongly polynomial algorithm.
---------------------------------------------------------------------
Self-correcting and self-organizing cellular arrays
Peter Gacs
Boston University and IBM Almaden Research Center
A computer in the future may be just a large crystal of smart
molecules grown artificially. The components work according to
a probabilistic transition rule in continuous time. All
non-uniformity in structure is created by the machine itself,
responding to the demands of the computation to be carried out. One
can also arrive to the problems of reliability and self-organization
presented by the above requirement starting from an interest in the
origins of life. A soup of chemical ingredients, in a noisy
environment, started organizing itself and became able to carry out
larger and larger computations reliably. No hypotheses will be
stated on how this actually happened in nature, nor practical designs
offered of reliable computing molecules. But an example of a
transition rule will be given that provably satisfies all the
requirements. Its organizational principles are therefore worth
studying both for the design of future reliable computers and for
ideas on understanding biological evolution.
The new construction builds on earlier experience with reliable
cellular automata. Self-organization and continuous time are new, as
well as the primitive concepts allowing a modular design that is
easier to analyze.
---------------------------------------------------------------------------
The Complexity of Circuit Value and Network Stability
Ashok Subramanian
The Circuit Value problem asks for the output of an acyclic network of
boolean gates, given its inputs. The Network Stability problem asks if a
given network, possibly cyclic, of boolean gates has stable configurations.
(A stable configuration of a network is an assignment of truth values to
the edges of the network that respects all the gate equations.) We study
the complexity of these problems as a function of the kinds of gates
allowed in the network. In our model, gates may have many outputs, but no
fanout is allowed outside gates. This model permits the study of the effect
of fanout on the complexity of the above problems. The results: If the
gates do not `preserve adjacency' (in other words, if they can `make
copies' of their inputs), the problems are usually complete for a standard
complexity class like P or NP. But if the gates preserve adjacency, we get
new classes of problems, classes that lie between Logspace and P, but seem
incomparable to the parallel complexity class NC.
We identify an interesting subset of the adjacency-preserving gates, those
that lack `scatter'. Intuitively, a gate lacks scatter if it is never
possible for a small number of inputs to influence a larger number of
outputs. We give a linear time algorithm for the network stability problem
over scatter-free networks, and an O*(sqrt(n)) time algorithm for
scatter-free circuit value.
One of the most fundamental of the new classes is the class CC. Problems
complete for CC include Comparator Circuit Value, Lexicographically-first
Maximal Matching, and problems related to Stable Matching. Our approach to
Stable Matching is to regard it as a network stability problem. This
approach yields fresh insights and new algorithms.
(This work represents work done towards my doctoral dissertation, under the
direction of Ernst Mayr.)
---------------------------------------------------------------------------
Seffi Naor
Stanford University
The problem of maximum flow in planar graphs was always investigated
under the assumption that there is only one source and one sink.
We are going to consider the case where there are many sources and sinks in
a directed planar graph.
An algorithm for the case when the demands of the sources
and sinks are known will be presented which
can be implemented in parallel in $O(\log ↑2n)$ time
using $O(n↑{1.5})$ processors, and in sequential $O(n↑{1.5})$ time.
It uses a novel idea of redirecting
the flow back from the sinks to the sources and then reducing the problem to
that of computing a circulation.
If the demands are not known, we will show how to compute the max flow
in the special case when the sources and sinks are on
the same face.
This result has two applications:
it places the problem of computing a perfect matching in a planar
bipartite graph in NC; it improves a previous parallel
algorithm for the case of a single source, single sink in a planar
directed (and undirected) graph,
both in terms of time complexity and processor bound,
and in its simple presentation.
This is joint work with Gary Miller.
∂06-Feb-89 1926 LOGMTC-mailer Seminar cancellation
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Feb 89 19:26:10 PST
Received: by csli.Stanford.EDU (4.0/inc-1.0)
id AA13897; Mon, 6 Feb 89 19:24:21 PST
Date: Mon 6 Feb 89 19:24:21-PST
From: Sol Feferman <SF@CSLI.Stanford.EDU>
Subject: Seminar cancellation
To: Logic@csli.Stanford.EDU
Message-Id: <602825061.0.SF@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
The seminar by Michael Beeson scheduled for tomorrow, Feb.7, has to bve
cancelled due to speaker's flu. We shall try to reschedule it.
-------
∂06-Feb-89 2000 misha@polya.Stanford.EDU Next AFLB
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Feb 89 19:59:56 PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA07449; Mon, 6 Feb 89 00:04:52 -0800
Date: Mon, 6 Feb 89 00:04:52 -0800
From: Michael Kharitonov <misha@polya.Stanford.EDU>
Message-Id: <8902060804.AA07449@polya.Stanford.EDU>
To: aflb-all@polya.Stanford.EDU
Subject: Next AFLB
The next AFLB will be on Tuesday, Feb 7, at 4:15 in room 352.
Dr. A. Razborov from the Steklov Institute in Moscow will
speak.
ON THE METHOD OF APPROXIMATIONS
The talk will be devoted to a recent paper of the speaker
submitted to the STOC conference. In this paper the question
as to how the method of approximations could be useful for obtaining
lower bounds of the circuit size of Boolean functions is formalized
and studied.
----------------------------------------------------------------------
Dr. Razborov will also give a survey talk on circuit complexity
at the special session of cs366 (Lower Bounds) on Monday at 3:15.
∂07-Feb-89 1041 debra@russell.Stanford.EDU REMINDER-Evening Seminar
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Feb 89 10:41:32 PST
Received: from localhost by russell.Stanford.EDU (4.0/inc-1.0)
id AA19001; Tue, 7 Feb 89 10:42:31 PST
Message-Id: <8902071842.AA19001@russell.Stanford.EDU>
To: evesem@russell.Stanford.EDU
Cc: debra@russell.Stanford.EDU, kuder@russell.Stanford.EDU
Subject: REMINDER-Evening Seminar
Date: Tue, 07 Feb 89 10:42:28 PST
From: Debra Alty <debra@russell.Stanford.EDU>
REMINDER
The next EVENING SEMINAR will be Wednesday, February 8th @ 7:30 pm in
the CSLI Cordura Conference Room.
Professor Herb Clark, Psychology Department, will be leading the
discussion.
The following will be served:
Italian Cheese Ball Cognac
Vegetable platter Wine
w/dip Beer
Crackers Sparkling Waters
Chocolates Coffee
Tea
Debra
∂07-Feb-89 1329 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Interval splitting problem
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Feb 89 13:29:37 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA10992; Tue, 7 Feb 89 13:24:51 -0800
Message-Id: <8902072124.AA10992@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 7 Feb 89 12:45:15 PST
Received: by BYUADMIN (Mailer R2.01A) id 0379; Mon, 06 Feb 89 22:23:19 MST
Date: Mon, 6 Feb 89 12:41:28 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Jon Turner <jst@JUSTIN.WUSTL.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Jon Turner <jst@JUSTIN.WUSTL.EDU>
Subject: Interval splitting problem
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
I'm looking for information on the following problem.
Given two intervals [a1,b1] and [a2,b2] we say that the first contains
the second if a1<a2 and b1>b2, that is we have strict containment on
both sides.
An interval [a,b] can be split into two intervals [a,c] and [c,b]
where a<c<b.
We say a set is proper if no interval in the set contains any other.
Now here is the problem. Given a set S of intervals, we want to construct
the smallest proper set S' that can be obtained from S by splitting intervals.
What if anything is known about the complexity of this problem?
Is anyone familiar with similar problems that might be useful
in helping establish its complexity?
Any help will be appreciated.
Jon Turner
jst@wucs1.wustl.edu
∂07-Feb-89 1355 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu A WORKSHOP ON CELLULAR AUTOMATA
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Feb 89 13:55:30 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA12881; Tue, 7 Feb 89 13:50:41 -0800
Message-Id: <8902072150.AA12881@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 7 Feb 89 13:16:28 PST
Received: by BYUADMIN (Mailer R2.01A) id 5894; Mon, 06 Feb 89 14:04:57 MST
Date: Mon, 6 Feb 89 09:59:50 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
617 Gerard Vichniac 253-5893 <gerard@BBN.COM>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: 617 Gerard Vichniac 253-5893 <gerard@BBN.COM>
Subject: A WORKSHOP ON CELLULAR AUTOMATA
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
A workshop on:
************************************************************
Cellular Automata and Modeling of Complex Physical Systems
************************************************************
will be held in les Houches, near Chamonix, France, from February 21 to
March 2, 1989.
The organizers are Roger Bidaux (Saclay), Paul Manneville (Saclay), Yves
Pomeau (Ecole Normale, Paris), and Gerard Vichniac (MIT).
The topics will include:
- - automata and discrete dynamical systems,
- - lattice-gas automata for fluid dynamics,
- - applications to solid-state physics (in particular, models of growth
and pattern formation),
- - parallel computation in statistical mechanics (in particular, in the
Ising model),
- - dedicated cellular-automata machines.
Workshops at les Houches are traditionally informal, there will be about
five talks a day, and ample time will be left for discussion.
A fee of 3700 FF includes full board lodging at the Physics Center in les
Houches.
Contact:
Paul Manneville, Roger Bidaux or Gerard Vichniac
Bitnet: MANNEV @ FRSAC11 Internet: gerard@bbn.com
tel.: 33 - 1 69 08 75 35 tel.: (617) 253 5893 (MIT)
fax: 33 - 1 69 08 81 20
telex: 604641 ENERG F
BITNET: MANNEV @ FRSAC11
∂07-Feb-89 1405 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Feasible Mathematics Workshop -- Announcement
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Feb 89 14:05:21 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA13721; Tue, 7 Feb 89 14:00:50 -0800
Message-Id: <8902072200.AA13721@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 7 Feb 89 13:24:15 PST
Received: by BYUADMIN (Mailer R2.01A) id 8635; Tue, 07 Feb 89 11:50:01 MST
Date: Tue, 7 Feb 89 11:38:41 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Sam Buss <sbuss@UCSD.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Sam Buss <sbuss@UCSD.EDU>
Subject: Feasible Mathematics Workshop -- Announcement
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
FEASIBLE MATHEMATICS WORKSHOP
Analyzing complexity of algorithms is both a practical
problem and a major area of theoretical research for computer
scientists, logicians, and mathematicians. Since the 1960's,
there has been an increasingly sophisticated classification
of algorithms into natural classes (e.g. P, NP, P-Space, Exp-time,
etc.) leading to a deeper understanding of the limits of feasible
computation.
More recently, researchers have begun investigating the logical
and mathematical consequences of "resource-bounded" (e.g. polynomial
time) mathematics. Active areas include: polynomial-time logics,
bounded versions of arithmetic and lambda calculus, proof theory
of feasible systems, feasible polymorphic languages, and polynomial
time versions of algebra and analysis. Such "feasible" mathematics
typically mixes logical techniques from proof theory and finite model
theory, as well as complexity and recursion theory, combinatorics,
and traditional mathematics.
There will be a Workshop from June 26-28, 1989 to be held at
Cornell University, under the auspices of MSI (Anil Nerode, Director),
entitled "Feasible Mathematics".
This workshop will gather together researchers from various
disciplines to discuss the state of the art in this area.
Researchers who are currently scheduled to speak include: M. Ajtai,
S. Buss, P. Clote, J. Crossley, S. Cook, J-Y.Girard, Y. Gurevich,
K-I Ko, D. Leivant, A. Nerode, J. Remmel, A. Scedrov, P. Scott,
G. Takeuti, and A. Urquhart.
The Organizers of the conference are:
Sam Buss Philip J. Scott
Dept. of Math Dept. of Math.
U.C.S.D University of Ottawa
La Jolla, CA 92093 Ottawa, Ont. Canada K1N 6N5
e-mail: sbuss@ucsd.edu e-mail: scpsg@uottawa.bitnet
For further information, contact the organizers or
for local information, contact Wil Kone (NVHY@Cornellc).
∂07-Feb-89 1428 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: Sorting on NxN Mesh.
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Feb 89 14:27:50 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA15380; Tue, 7 Feb 89 14:23:25 -0800
Message-Id: <8902072223.AA15380@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 7 Feb 89 13:37:23 PST
Received: by BYUADMIN (Mailer R2.01A) id 1248; Mon, 06 Feb 89 22:27:25 MST
Date: Mon, 6 Feb 89 12:43:27 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Sandeep Sen <ss@CS.DUKE.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Sandeep Sen <ss@CS.DUKE.EDU>
Subject: Re: Sorting on NxN Mesh.
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
In article <8901242125.AA29314@jade.berkeley.edu> you write:
>I would appreciate any suggestions, references or solutions for the following
>problem:
> We have a SIMD, 4-connected, NxN Mesh Connected Computer (MCC) and
> the following
> algorithm for sorting on it. The algorithm is an extension of the
> so called "odd-even transposition sorting" (OETS) algorithm for a
....
> couple each processor first with its upper neighbour, then with its
> lower, its left and finally irs right neighbour and perform a compare-
> and-then-possibly-swap operation. More precisely in time T the NxN
> grid G={(i,j): i, j in P /* i for rows */} is partitioned in
> { <(2i-1,j), (2i, j)> for all i, j } when T mod 4 = 0
> { <(2i,j), (2i+1,j)> for all i, j} when T mod 4 = 1
> { <(i,2j-1), (i,2j)> for all i, j} when T mod 4 = 2 and
> { <(i,2j), (i,2j+1)> for all i, j} when T mod 4 = 3,
> and all these pairs of processors compare their contents and possibly
> swap them.
> It is obvious again that it is a sorting algorithm but what is its
> time complexity? Is it linear ? is the question. I suspect it is not,
> because if it were no other sorting alg. for the NxN mesh should have
> been invented; this seems far simpler than any other I have seen.
> But I do not have a bad example for this alg. Do you?
>Thanks in advance
>
>Michalis Kolountzakis,
>Mathematics Dept, Univ. of Crete, Greece
>
You are right - this algorithm is not linear (in fact it is quadratic).
The bad example is partition the array vertically into two halves - fill
0's on the left and 1's on the right. I do not have a formal proof of this
- I had run some simulations which made it clear that it is quadratic. I
did come up with some informal arguments which I wouldn't bother to describe
now. Since this is for a fixed input and the data movements are very
regular you can convince yourself by working on a few examples.
What works much better (but still not linear O(nlogn)) and is again very
simple is a row-column sort. You can look it up in a paper in the
Proc. of the Internaional Conference on Parallel Processing 1986
entitled "Shear-sort - a true 2-D sorting network ..." by Scherson, Sen
and Shamir
(Incidentally in the conclusion we make the observation about the 2-D
even-odd transposition being not efficient).
A further development along these lines (i.e. simple row-column sorts)
was reported in the Proc. of the ACM Symp. on Theory of Computing 1986
by Schnorr and Shamir entitled `An optimal algorithm for mesh-conn arrays'.
I am assuming that you are familiar with the other work on mesh-sorting
(i.e. the more complicated ones) but if you need any further information,
I will be glad to help. (I had spent more than a year sorting numbers on
mesh).
- Sandeep Sen
∂07-Feb-89 1455 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu collision in DES: distributed and probabilistic algorithm
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Feb 89 14:55:38 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA17801; Tue, 7 Feb 89 14:51:22 -0800
Message-Id: <8902072251.AA17801@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 7 Feb 89 13:49:13 PST
Received: by BYUADMIN (Mailer R2.01A) id 4483; Mon, 06 Feb 89 23:30:40 MST
Date: Mon, 6 Feb 89 12:45:29 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Jac. Quisquater" <mcvax!prlb2!quisquat@UUNET.UU.NET>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Jac. Quisquater" <mcvax!prlb2!quisquat@UUNET.UU.NET>
Subject: collision in DES: distributed and probabilistic algorithm
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
We (Jean-Paul Delescaille and Jean-Jacques Quisquater) were able
to find 3 collisions in DES using a network of workstations
during some weeks.
Definition of a collision: given a message M and an cryptographic
algorithm f with 2 parameters M and K (the key), a collision is a
pair (K1, K2) such that
f (M, K1) = f (M, K2),
that is, for a fixed message M and using a cryptographic
algorithm f, the key K1 and the key K2 give the SAME encrypted
message.
Jean-Jacques devised a new probabilistic distributed asynchronous
algorithm for finding collisions without any sorting and with a
small storage (a la Pollard). We used a fast implementation of
DES in C (by Jean-Paul: about 2000 * (encryption + change of key)
/second/machine)
We used the idle time of a network of 20 SUN-3's and 10 microVAXes
(a la Lenstra and Manasse). Total: about 100 Mips during one month.
37
2 encryptions performed (about 20 potential collisions) only in
software!
The message M is 0404040404040404 (hexadecimal form) for
the 3 collisions.
Collision 1: found Fri Jan 13 23:15 GMT (birthday of Jean-Jacques!
Yes, it is another birthday attack (Hi! Don Coppersmith)).
cipher = F02D67223CEAF91C
K1 = 4A5AA8D0BA30585A
K2 = suspense!
Collision 2: found Fri Jan 20 19:13 GMT
cipher = E20332821871EB8F
K1, K2 = suspense!
Collision 3; found Fri Feb 3 03:22 GMT
suspense!
Conclusion: Friday is a good day for finding collisions :-)
Well, there is a problem because there is no proof we effectively
found such collisions.
Question 1: Find a protocol for proving or for convincing you
that we know K2 for collision 1 (zero-knowledge protocols are useful
in this context).
Question 2: Find a protocol for proving or convincing that we know
K1 and K2 for collision 2 (idem).
Question 3: Find a protocol for proving or convincing that we know
3 different collisions (idem).
Useful information: the nice paper by Brassard, Chaum and Crepeau,
``Minimum disclosure proofs of knowledge'', 1987.
The complete information will be given at EUROCRYPT '89, Houthalen,
Belgium, with the restriction that the submitted abstract is
accepted :-) The paper will be sent in April if you want it.
Thanks are due to Paul Branquart, Frans Heymans, Michel Lacroix,
Vincent Marlair, Marc Vauclair, the members of PRLB for permission
and active help in the effective implementation of the distributed
algorithm on their workstations.
Warning: There is no implication about the security of DES used
for encryption. Indeed these experiments only prove that DES is a
good random mapping (a necessary property for any cryptographic
algorithm). However the use of DES for protecting the integrity of files
is not very easy and needs very careful studies.
Jean-Jacques Quisquater,
(Program chairman of EUROCRYPT '89)
∂07-Feb-89 1505 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu CALL FOR PAPERS -Conference BCTCS5
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Feb 89 15:05:10 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA18496; Tue, 7 Feb 89 15:01:01 -0800
Message-Id: <8902072301.AA18496@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 7 Feb 89 14:04:47 PST
Received: by BYUADMIN (Mailer R2.01A) id 5328; Mon, 06 Feb 89 23:33:30 MST
Date: Mon, 6 Feb 89 19:42:06 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Costas S. Iliopoulos" <UHAC018%VAXA.RHBNC.AC.UK@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Costas S. Iliopoulos" <UHAC018%VAXA.RHBNC.AC.UK@Forsythe.Stanford.EDU>
Subject: CALL FOR PAPERS -Conference BCTCS5
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
CALL FOR PAPERS
Fifth British Colloquium for Theoretical Computer Science
Royal Holloway and Bedford New College
University of London, 11th-13th April 1989
The Fifth British Colloquium for Theoretical Computer Science (BCTCS)
will take place at Royal Holloway and Bedford New College of the
University of London at Egham, Surrey, beginning on the morning of
Tuesday, 11th April and ending at lunchtime on Thursday 13th.
The BCTCS was established at Leeds in 1985, and has since been held at
Warwick, Leicester and at Edinburgh in 1988. The colloquium aims to
provide a forum for theoreticians to learn of new developments in the
broad areas including Logic and Semantics of Programs, Formal Methods,
Term Rewriting, Specification and Verification, Logic Programming, Data
Structures and Complexity, Computational Algebra, Cryptography,
Parallel Computation, Formal Languages, Artificial Intelligence. The
meeting is informal and provides an opportunity to exchange ideas with
colleagues and research students. Several book publishers will also be
displaying, among others Wiley, McMillan, McGraw-Hill, Prentice-Hall,
Springer, Oxford University Press and Cambridge University Press.
There will be eight invited mainly survey lectures intended to cover
the spectrum of interests in theoretical computer science; the list of
speakers will include
A. Apostolico University of Purdue
R.L. Backhouse University of Groningen
R. Cole Courant Institute, New York
J.A. Goguen University of Oxford, PRG
R. Hindley University of Wales
J.L. Lloyd University of Bristol
M. Smyth Imperial College
These lectures will be complemented by many shorter, contributed
talks for which a submission form follows below.
Abstracts of all talks will be published in the
Bulletin of the EATCS.
A registration form is attached and should be returned by all who wish
to attend. The registration fee for academics will be L15 for forms
returned by 15th March and L20 thereafter. For non-academics there
will be a fixed rate of L50. Those interested in contributing should
fill out the attached form and return it by 15th March.
(Note: L stands for pounds sterling)
BCTCS5
Department of Computer Science
Royal Holloway and Bedford New College
University of London
Egham, Surrey TW20 0EX, UK
E-mail
JANET: bctcs5@uk.ac.rhbnc.vaxb
BITNET: bctcs5@vaxa.rhbnc.ac.uk
ARPA: bctcs5%vaxa.rhbnc.ac.uk@nss.cs.ucl.ac.uk
Local Organising Committee:
Alan Davies
Costas Iliopoulos
John Shawe-Taylor
The organisers thank IBM United Kingdom Trust for their financial assistance.
---------------------------------------------------------------------------
FIFTH BRITISH COLLOQUIUM of THEORETICAL COMPUTER SCIENCE
Registration Form
Name...........................................
Address......................................................
....................................................
......................................................
Telephone ................................................
Electronic Mail....................
We are offering two standards of accommodation (including breakfast)
both in the original 19th century College building. Shared bathroom and
shower facilities are available for both. The superior standard rooms
are newly converted fifth floor rooms with washbasins. The Conference
Dinner will be held in the College's famous Picture Gallery on Tuesday
evening. Please reserve accommodation and meals by ticking the
appropriate boxes below. Special student rates are available for the
standard accommodation.
student standard superior
Monday dinner, accommodatioN [ ]L18 [ ]L20 [ ]L25
Tuesday lunch [ ]L3.50 [ ]L4 [ ]L4
Tuesday conference dinner,
Accommodation [ ]L25 [ ]L30 [ ]L35
Wednesday lunch [ ]L3.50 [ ]L4 [ ]L4
Wednesday dinner, accommodation [ ]L18 [ ]L20 [ ]L25
Thursday lunch [ ]L3.50 [ ]L4 [ ]L4
Extra Conference dinner [ ]L12 [ ]L14 [ ]L14
at a total cost of ..........pounds sterling
I enclose a (non-refundable) registration fee of L15
(L20 if after 15th March, L50 if non-academic)
made payable to RHBNC. Details of how to reach the College will
be forwarded to those who have registered by 1st April.
----------------------------------------------------------------------------
Fifth British Colloquium for Theoretical Computer Science
Royal Holloway and Bedford New College
University of London
11-13 April 1989
APPLICATION FORM for
Contributed Talks of 25 minutes duration
Name.................................................
Affiliation...........................................
Title of Talk:
Abstract (of not more than half a page):
This form should be returned by 15th March to the address above.
∂07-Feb-89 1543 X3J13-mailer What-a-Guy!
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 7 Feb 89 15:42:54 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 7 Feb 89 18:24:35 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 7 Feb 89 18:38:45 EST
Received: from godot.think.com by fafnir.think.com; Tue, 7 Feb 89 16:00:53 EST
Received: by godot.think.com; Tue, 7 Feb 89 16:00:48 EST
From: alison@Think.COM
Message-Id: <8902072100.AA18029@godot.think.com>
To: staff@Think.COM
Cc: alison@Think.COM
Subject: What-a-Guy!
Date: Tue, 07 Feb 89 16:00:46 EST
Resent-To: x3j13@sail.stanford.edu
Resent-From: Barry Margolin <barmar@Think.COM>
Resent-Date: Tue, 7 Feb 89 18:40 EST
Resent-Message-Id: <19890207234021.1.BARMAR@OCCAM.THINK.COM>
Congrats to Guy Steele for receiving the 1988 ACM Grace Murray Hopper
Award! Below is a press release written by Jim Adams of the ACM.
*******************************************************************
GUY L. STEELE JR.. RECEIVES 1988 ACM GRACE MURRAY HOPPER AWARD
Dr. Guy Steele Jr., Senior Scientist at the Thinking Machines
Corporation, is the recipient of the 1988 ACM Grace Murray Hopper Award.
The Award will be presented to Dr. Steele on Wednesday, February 22,
1989, at the ACM Computer Science Conference at Louisville, Kentucky, in
recognition of, "his general contributions to the development of Higher
Order Symbolic Programming, principally for his advancement of lexical
scoping in LISP".
Guy L. Steele Jr. has published more than two dozen technical papers on
the subject of the LISP language and its implementation, including a
series with Gerald Jay Sussman that defined the Scheme dialect of LISP.
He is author of co-author of three books: Common LISP: The Language,
(Digital Press, 1984); C: A Reference Manual, (Prentice-Hall, 1984 and
1987); and The Hacker's Dictionary, (Harper & Row, 1983). At Thinking
Machines Corporation, Dr. Steele is responsible for the design and
implementation of parallel programming languages and other systems
software for the Connection Machine computer systems.
Dr. Steele received his A.B. degree in applied mathematics from Harvard
College (1975) and his S.M. and Ph.D. in computer science and artificial
intelligence from M.I.T. in 1977 and 1980, respectively.
The award, named in honor of computer pioneer, Admiral Grace Murray
Hopper, has been given annually since 1971 to recognize young persons
who have made an outstanding technical contribution to the computer
industry while 30 years of age or younger.
*****************************************************************
∂07-Feb-89 1735 LOGMTC-mailer Carl Gunter Reminder
Received: from ra.stanford.edu by SAIL.Stanford.EDU with TCP; 7 Feb 89 17:35:27 PST
Received: by ra.stanford.edu (5.59/25-eef) id AA08164; Tue, 7 Feb 89 17:34:01 PDT
Date: Tue, 7 Feb 89 17:34:01 PDT
From: John Mitchell <jcm@ra.stanford.edu>
Message-Id: <8902080134.AA08164@ra.stanford.edu>
To: csd@score, logmtc@sail
Subject: Carl Gunter Reminder
INHERITANCE AND EXPLICIT COERCION
speaker:
Carl Gunter (Penn CIS)
work joint with:
Val Breazu-Tannen (Penn CIS)
Thierry Coquand (INRIA)
Andre Scedrov (Penn Mathematics)
time and place:
Wed Feb 8 at 4:15 PM in MJH 352
We present a method for providing semantic interpretations for
languages which feature INHERITANCE in the framework of statically
checked, rich type disciplines. We illustrate our approach on an
extension of the language Fun of Cardelli and Wegner, which we
interpret via a translation into an extended polymorphic lambda
calculus. Our approach interprets inheritances in Fun as COERCION
FUNCTIONS already DEFINABLE in the target of the translation. Existing
techniques in the theory of semantic domains can be then used to
interpret the extended polymorphic lambda calculus, thus providing
many models for the original language. Our method allows the
simultaneous modeling of PARAMETRIC POLYMORPHISM, RECURSIVE TYPES, and
INHERITANCE, something that was regarded as problematic because of the
seemingly contradictory characteristics of inheritance and type
recursion on higher types.
We identify the main difficulty in providing interpretations for
explicit type disciplines featuring inheritance, namely that programs
can type-check in more than one way. Since interpretations
follow the type-checking derivations, COHERENCE theorems are required,
(that is, one must prove that the meaning of a program does not depend on the
way it was type-checked), and we do prove them for our semantic method.
Interestingly, proving coherence in the presence of recursive types,
variants, and abstract types forced us to reexamine fundamental equational
properties that arise in proof theory (in the form of commutative reductions)
and domain theory (in the form of strict vs. non-strict functions).
∂08-Feb-89 0736 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Program Extraction / Calculus of Constructions
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Feb 89 07:36:35 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA16427; Wed, 8 Feb 89 07:32:30 -0800
Message-Id: <8902081532.AA16427@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Wed, 8 Feb 89 07:35:16 PST
Received: by BYUADMIN (Mailer R2.01A) id 9208; Wed, 08 Feb 89 08:34:00 MST
Date: Wed, 8 Feb 89 09:04:50 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Dwight Spencer <blake!ogccse!dwights@BEAVER.CS.WASHINGTON.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Dwight Spencer <blake!ogccse!dwights@BEAVER.CS.WASHINGTON.EDU>
Subject: Program Extraction / Calculus of Constructions
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
At the recent POPL '89 conference in Austin, Texas, the following paper
was presented:
Extracting {F sub omega}'s programs from prooofs in the calculus of
constructions - C. Paulin-Mohring (INRIA and LIENS)
I hope to locate someone who attended this conference and is willing to send
me a copy of this paper. Please contact me by E-mail / phone.
I am also searching for any very recent work/bibliographies concerning program
extraction from various type calculi and also the calculus of constructions
as a specification/design language.
Thanks in advance for any help.
- Dwight Spencer
Dept. of Computer Science & Engineering
Oregon Graduate Center, Beaverton, Oregon, USA, 97006-1999
E-mail: dwights@cse.ogc.edu Phone: (503) 690-1121 x7369
∂08-Feb-89 0752 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Feb 89 07:52:03 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA16755; Wed, 8 Feb 89 07:47:56 -0800
Message-Id: <8902081547.AA16755@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Wed, 8 Feb 89 07:50:40 PST
Received: by BYUADMIN (Mailer R2.01A) id 9561; Wed, 08 Feb 89 08:47:36 MST
Date: Wed, 8 Feb 89 09:08:43 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"research.att.com Joan Feigenbaum jf" <jf@RESEARCH.ATT.COM>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "research.att.com Joan Feigenbaum jf" <jf@RESEARCH.ATT.COM>
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
This is the second anouncement for the first meeting of
THE ?WHAT EXIT? SEMINAR SERIES,
sponsored by DIMACS, the new NSF Science and Technology Center
for DIscrete MAth and Computer Science.
Tentatively, we are planning to sponsor a series of
day-long seminars, each organized around a specific topic
in discrete math or theoretical computer science. The
participating institutions are Rutgers, Princeton, Bellcore,
and AT&T Bell Labs, and the location of the meetings will
rotate among these four.
*****************************************************************
Topic: Approximation Algorithms for NP-Complete Problems
Date: Friday, March 3, 1989
Time of first talk: 10:30 a.m.
Location: Princeton
Speakers:
David Shmoys (MIT):
Using Linear Programming in the Design and Analysis of
Approximation Algorithms
Ravi Kannan (CMU):
Sampling from a Convex Set and Volume Computation
Mihalis Yannakakis (AT&T-BL):
Approximation and Complexity Classes
Directions:
Park in Lot 21, which you reach as follows: Assume you start
on Nassau Street (a.k.a. Rt. 27) going southwest (i.e., away from
New Brunswick, towards Trenton). Turn left on Washington Road
(at a light). Drive on Washington past Fine Hall and Palmer
Stadium. Turn left onto Faculty Road (at a light). If you
get to a bridge, you have gone too far. The first real street
onto which you can turn left off Faculty is Fitzrandolf. (There
is a previous left, but it is into an alley as opposed to a real
street.) Take that left, and Lot 21 is on your left.
The talks will take place in the Woodrow Wilson School, on the
corner of Washington Street and Prospect Avenue. To get there
from Lot 21, go back to Fitzrandolf and walk in the same direction
in which you were driving before you entered the lot. Go left
on Prospect and continue until Washington. The Woodrow Wilson
School is a large white building.
It takes 10 to 15 minutes to walk from Lot 21 to the Woodrow
Wilson School. So allow enough time!
*****************************************************************
Joan Feigenbaum
jf@research.att.com
∂08-Feb-89 0828 HEMENWAY@Score.Stanford.EDU Round 1 Meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Feb 89 08:27:53 PST
Date: Wed 8 Feb 89 08:22:24-PST
From: Sharon Hemenway <HEMENWAY@Score.Stanford.EDU>
Subject: Round 1 Meeting
To: phd-adm@Score.Stanford.EDU
Reply-To: Hemenway@Score.Stanford.EDU
Message-ID: <12469058201.21.HEMENWAY@Score.Stanford.EDU>
In the continuing battle to schedule the Round 1 meeting, may I ask
you each to let me know if you could make the meeting on each of
Monday, Feb. 20, Tuesday, Feb. 21 and Wednesday, Feb. 22? For now,
let's assume that it will be at 3 pm (although if we decide on
Monday, the holiday, we will have much more flexibility).
Many thanks -- I'll compile the answers and get back to you with a
firm date as quickly as possible.
Sharon
-------
∂08-Feb-89 1107 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Ruzena Bacjsy
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Feb 89 11:06:58 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 8 Feb 89 11:02:28-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AB24294; Wed, 8 Feb 89 11:00:34 -0800
Date: Wed, 8 Feb 1989 11:00:31 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score
Subject: Ruzena Bacjsy
Message-Id: <CMM.0.87.602967632.chandler@polya.stanford.edu>
will be arriving in Palo Alto tomorrow in preparation for her part in the
Forsythe Lectures next week. I am working with her to put a schedule
together. If you would like to chat with her please contact me and I'll set
some time aside for you to visit with her.
∂08-Feb-89 1607 @polya.Stanford.EDU:tah@linz MTC Seminar
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Feb 89 16:07:01 PST
Received: from linz.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA08708; Wed, 8 Feb 89 14:30:43 -0800
Received: by linz.stanford.edu (5.59/25-eef) id AA05463; Wed, 8 Feb 89 14:26:54 PDT
Message-Id: <8902082226.AA05463@linz.stanford.edu>
To: lop@polya
Subject: MTC Seminar
Reply-To: tah@cs.stanford.edu
Date: 08 Feb 89 14:26:49 PST (Wed)
From: Tom Henzinger <tah@linz>
Friday Feb. 10 noon, MJH 301:
Carl Gunter from Penn will give an informal presentation about work in
progress, on the connection between Petri nets and Linear Logic.
∂08-Feb-89 1622 misha@polya.Stanford.EDU AFLB TOMORROW!!
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Feb 89 16:21:58 PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA16470; Wed, 8 Feb 89 16:16:28 -0800
Date: Wed, 8 Feb 89 16:16:28 -0800
From: Michael Kharitonov <misha@polya.Stanford.EDU>
Message-Id: <8902090016.AA16470@polya.Stanford.EDU>
To: aflb-all@polya.Stanford.EDU
Subject: AFLB TOMORROW!!
The next AFLB is TOMORROW, Feb 9, at 12:30 in room 352.
ON A GENERAL FRAMEWORK FOR DE-RANDOMIZING PARALLEL ALGORITHMS
Rajeev Motwani
We present a fairly general technique for converting RNC
algorithms into NC algorithms. Our approach is based on a
parallel implementation of the Method of Conditional
Probabilities due to Joel Spencer. This method was used
to convert probabilistic proofs of existence of combinatorial
structures into polynomial time deterministic algorithms.
It had the apparent drawback of being extremely sequential
in nature. We show that, under certain general conditions,
it is possible to use this technique for devising deterministic
parallel algorithms.
We use our technique to devise NC algorithms for
various problems including set balancing problems,
near-optimal edge coloring of graphs, finding independent
sets in hypergraphs and lattice approximation problems.
Simple RNC algorithms were known for each of these problems
previously but no deterministic NC algorithms had been
devised.
[Joint work with Seffi Naor (Stanford University) and
Moni Naor (IBM-ARC). ]
-----------------------------------------------------------------
Also Mauricio Karchmer will speak early next week, Tuesday or
Monday (watch this space!)
∂08-Feb-89 1651 TAJNAI@Score.Stanford.EDU need FORUM RSVP
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Feb 89 16:51:36 PST
Date: Wed 8 Feb 89 16:47:36-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: need FORUM RSVP
To: faculty@Score.Stanford.EDU
Message-ID: <12469150169.39.TAJNAI@Score.Stanford.EDU>
This is a reminder, if you have not let us know the meal functions you
plan to attend during Forum week, please let me know by Friday morning
latest. We have to give guarantees for numbers.
Tuesday, buffet supper, Faculty club, 6:00 p.m.
WEd. breakfast, Tresidder, 8:00 a.m.
Wed. lunch, tresidder, 12:00
Wed. banquet, Faculty Club, 6:00 social hour, 7:00 banquet
Thursday lunch, Tresidder, 12:15
Tajnai@Score
Hiller@Score
Carolyn
-------
∂09-Feb-89 0436 X3J13-mailer Preview of things to come from editorial committee
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 9 Feb 89 04:35:59 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA17564; Thu, 9 Feb 89 04:34:21 PST
Message-Id: <8902091234.AA17564@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 9 Feb 89 07:31
To: x3j13@sail.stanford.edu
Subject: Preview of things to come from editorial committee
It's time to begin to come to closure on the standard. I propose we do
this in pieces first, and then finally vote on the document as a whole.
To do this we'll need several letter ballots and of course, votes
at X3J13 meetings. Following are lists of what will be included in the
first two votes. The issue CUT-OFF-DATES contains the complete list
of things we need to agree on, and a proposed segmenting of voting on
those things.
The next few messages you will receive are the issues that will be
included in the letter ballot. Next week I'll send the issues that
are to be voted on at the 3/89 meeting. To access the sections of the
standard that will be voted on: hudson.dec.com, ftp_user merrychristmas,
filenames: letter-ballot-feb-21.dvi, letter-ballot-feb-21.txt. If you
want to build your own .dvi file, you'll need the following files:
s1800.portability-issues, s2300.classes, s2400.slots, s2500.objects,
s6100.introduction, kcamfont.tex, kcmacros.tex, macros2a.tex,
letter-ballot-feb-21.tex (this is the top-level file, the one that
includes all the others).
These files are small enough to be mailed, so let me know if you can't
get FTP access and want to review them before you get them in the letter
ballot. Note that 2.3, 2.4, and 2.5 are just rearrangements of parts of
CLOS Chapter 1. That is why there is such a short review time for them,
presumably we've all just reviewed them.
Letter ballot (2/21/89)
CUT-OFF-DATES
FONTS
ERROR-TERMINOLOGY
TOC
1.8 Portability Issues
2.3 Classes
2.4 Slots
2.5 Objects
6.1 Intro to catalog of tools
3/89 meeting
EXTRA-SYNTAX
EXTRA-OPTIONAL-KEYWORD-ARGUMENTS
UNSPECIFIED-DATATYPES
EXTRA-RETURN-VALUES
UNSOLICITED-MESSAGES
MACRO-AS-FUNCTION
CONFORMANCE-POSITION
EXTENSIONS-POSITION
SUBSETTING-POSITION
Chapter 1 - all parts except 1.8 will be voted on separately, then
Chapter 1 as a whole will be voted on.
2.1 Introduction
2.2 Types
5.1 Errors
5.2 Input/Output
5.3 Interface with the Programming Environment
5.4 Generalized Reference
kc
∂09-Feb-89 0437 X3J13-mailer Issue: CUT-OFF-DATES
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 9 Feb 89 04:37:32 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA17595; Thu, 9 Feb 89 04:35:56 PST
Message-Id: <8902091235.AA17595@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 9 Feb 89 07:33
To: x3j13@sail.stanford.edu
Subject: Issue: CUT-OFF-DATES
Issue: CUT-OFF-DATES
References: Working draft of the standard
Category: Policy
Edit history: 20-DEC-88, Version 1 by Chapman
9-JAN-89, Version 2 by Chapman
25-JAN-89, Version 3 by Chapman
7-FEB-89, Version 4 by Chapman
Problem Description:
The X3J13 committee has informally agreed that a 12/89 standard is
a doable goal. However, the standard has to be reviewed by a large
number of people outside the X3J13 committee. We must allow plenty
of time for these reviews, and should therefore plan our internal
reviews and "document freeze" accordingly.
Proposal (CUT-OFF-DATES:ESTABLISH)
Item Dates
________________________________________________Final Changes___Letter Ballot__
Format of tool descriptions 11/1/88 2/21/89
Meaning of each item in each tool description 11/1/88 2/21/89
Fonts 2/1/89 2/21/89
Changes via clean-up to existing functions 4/1/89
Adding functions via clean-up 3/15/89
Conformance issues 3/1/89 mtg
Error terms 2/19/89 2/21/89
Changes to TOC 2/19/89 2/21/89
Contents of sections:
Chapter 1. Introduction 4/1/89 mtg
CONTENTS
1.1 Scope, Purpose, and Application 3/1/89 mtg
1.2 Organization of the Document 3/1/89 mtg
1.3 Referenced Publications 3/1/89 mtg
1.4 Definitions 3/1/89 mtg
1.5 Compliance 3/1/89 mtg
1.6 Implementation-defined Features 3/15/89 mtg
Values
Results
Data Representation and Typing
Program and Control Structure
Comparisons
Numerical Calculations
User Interface
Input/Output
Compiling
Miscellaneous
Programming Environment
1.7 Language Extensions 3/1/89 mtg
1.8 Portability Issues 2/19/89 2/21/89
Chapter 2. Objects and Types 4/1/89 4/14/89
CONTENTS
2.1 Introduction 3/15/89 mtg
2.2 Types 3/22/89 mtg
Type Hierarchy and Relationships
Data Type Definition
Type Specifiers
2.3 Classes 2/19/89 2/21/89
Introduction to Classes
Metaclasses
Standard Metaclasses
Defining Classes
Creating Instances of Classes
Inheritance
Inheritance of Class Options
Examples
Determining the Class Precedence List
Topological Sorting
Examples
Redefining Classes
Modifying the Structure of Instances
Initializing Newly Added Local Slots
Customizing Class Redefinition
Extensions
Integrating Types and Classes
2.4 Slots 2/19/89 2/21/89
Introduction to Slots
Accessing Slots
Inheritance of Slots and Slot Options
2.5 Objects 2/19/89 2/21/89
Object Creation and Initialization
Initialization Arguments
Declaring the Validity of Initialization Arguments
Defaulting of Initialization Arguments
Rules for Initialization Arguments
Shared-Initialize
Initialize-Instance
Definitions of Make-Instance and Initialize-Instance
Changing the Class of an Instance
Modifying the Structure of the Instance
Initializing Newly Added Local Slots
Customizing the Change of Class of an Instance
Reinitializing an Instance
Customizing Reinitialization
Meta-Objects
Standard Meta-objects
Chapter 3. Object Syntax 4/14/89 5/14/89
CONTENTS
3.1 Character Reader 4/1/89 4/14/89
Reader Algorithm
Numbers as tokens
Symbols as tokens
Macro character collection
3.2 Object Syntax 4/8/89 4/14/89
Chapter 4. Evaluation and Compilation 5/1/89 5/14/89
CONTENTS
4.1 Evaluation Model 4/14/89 5/14/89
Introduction
Context and Environment
The Model
Form evaluation
Self-evaluating forms
Symbols as forms
Conses as forms
Return values
Shadowing
Extent
Generic Functions and Methods
Introduction to Generic Functions
Introduction to Methods
Agreement on Parameter Specializers and Qualifiers
Congruent Lambda-Lists for All Methods of a Generic Function
Keyword Arguments in Generic Functions and Methods
Method Selection and Combination
Determining the Effective Method
Standard Method Combination
Declarative Method Combination
Built-in Method Combination Types
Inheritance of Methods
Lambda-expressions
4.2 Compilation 4/22/89 5/14/89
Chapter 5. Other Topics 4/1/89 4/14/89
CONTENTS
5.1 Errors 3/15/89 mtg
Error Terminology
Condition System Concepts
Condtion System Data Types
Condtion System Operation
5.2 Input/Output 3/8/89 mtg
Files
Character and Binary Input/Output
Loading
5.3 Interface with the Programming Environment 3/8/89 mtg
Top level loop
Environment inquiry
Time
5.4 Generalized Reference 3/8/89 mtg
The following sections in the standard:
Chapter 6. Catalog of Tools (A-M) 6/14/89
A-F plus non-alphabetics 4/1/89 4/14/89
G-M 5/1/89 5/14/89
Chapter 7. Catalog of Tools (N-Z) 6/30/89
N-S 6/1/89 6/14/89
T-Z 6/14/89 6/30/89
Glossary 4/1/89 4/14/89
The following will be decided by a letter ballot mailed on 2/21/89:
This list of cut-off-dates (issue CUT-OFF-DATES)
Format of tool descriptions (in Chapters 6 and 7)
Meaning of each item in each tool description (Section 6.1)
Fonts used for distinguishing special words and phrases (issue FONTS)
Error terms (issue ERROR-TERMINOLOGY)
Table of Contents of the standard (issue TOC)
The following sections in the standard:
1.8 Portability Issues
2.3 Classes
2.4 Slots
2.5 Objects
The following will be decided at the 3/89 meeting:
Conformance issues (the issues presented at the 1/89 meeting)
Chapter 1. Introduction (even though all parts have been voted on,
chapter 1 as a whole should be voted on)
The following sections in the standard:
1.1 Scope, Purpose, and Application
1.2 Organization of the Document
1.3 Referenced Publications
1.4 Definitions
1.5 Compliance
1.6 Implementation-defined Features
1.7 Language Extensions
2.1 Introduction
2.2 Types
5.1 Errors
5.2 Input/Output
5.3 Interface with the Programming Environment
5.4 Generalized Reference
The following will be decided by a letter ballot mailed on 4/14/89:
Chapter 2. Objects and Types (ditto, chapter 1)
Chapter 5. Other Topics (ditto, chapter 1)
Glossary
The following sections in the standard:
3.1 Character Reader
3.2 Object Syntax
Chapter 6, A-F plus non-alphabetics
The following will be decided by a letter ballot mailed on 5/14/89:
Chapter 3. Object Syntax (ditto, chapter 1)
Chapter 4. Evaluation and Compilation (ditto, chapter 1)
The following sections in the standard:
4.2 Compilation
G-M
The following will be decided by a letter ballot mailed on 6/14/89:
Chapter 6. Catalog of Tools (A-M) (ditto, chapter 1)
The following section in the standard:
N-S
The following will be decided by a letter ballot mailed on 6/30/89:
Chapter 7. Catalog of Tools (N-Z) (ditto, chapter 1)
The following section in the standard:
T-Z
All comments received according to this schedule will be incorporated
by 6/30/89. Any comments received after the dates listed above will
only be considered if they are of an extreme nature, if they impact
the correctness of the document. Otherwise the comments will be filed
and reserved for the next standard.
To change these dates, a 2/3 vote of the editorial committee
or a majority vote of X3J13 is required.
Rationale:
In order to complete this standard and move on to the next version,
we need to establish dates after which changes will not be allowed.
Current Practice:
None.
Adoption Cost:
None.
Benefits:
Establishing cut-off dates will encourage reviewers to complete
a thorough review in a timely manner.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
Comment:
Larry Masinter says:
"There are a couple of areas where I expect some further work that might
impact these dates:
a) pathname functions
I'm still hoping to get some cleanup of many of the pathname issues
b) errors signalled, by name
I'm still hoping that we can get at least a partial listing, for each
function, of the possible errors signalled, under what circumstances.
c) pending cleanups
There will probably be 10-15 cleanup issues dealing with ambiguities that
will drag out beyond 3/89. I hope not, but I'm trying to be realistic;
there are just too many "open" issues left."
Jeff Rosenking says:
I agree with the CUT-OFF-DATES proposal and believe that a
strict adherence to it may allow us to complete the standard in
the desired time frame. If an exception situation arises then
the exception clause may be voted on by the editorial committee
and/or X3J13 as a whole; I think this provides enough room for
modification, if it is needed.
One concern I have is on the cut-off-date for the Format of tool
descriptions. The apparent need to modify (shorten) the standard
will most likely require a change in the tool description format.
I personally favor having the present format that we adopted, if
I was drafting the standard for my own use. BUT, since I am not
the only intended user of this standard and since we are not the
only group (country) I agree that we have to consider the
feelings of all those who may use this document.
I will support a modification to the tool formats to extract the
examples field and put them in a library or appendix section. If
addiontal measures need to be taken to "trim" the standard we may
want to limit the tool formats to just include a DESCRIPTION,
SYNTAX, ARGUMENTS and VALUES field, with the other fieldsput into
supplementary volumes of the standard. Perhaps the Japanese, and
also the Germans, English and French, will provide alternative
methods for making the standard more concise. Their input and
agreement, on ANSI Common LISP, will make the standard much more
valuable.
∂09-Feb-89 0440 X3J13-mailer Issue: FONTS
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 9 Feb 89 04:40:24 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA17692; Thu, 9 Feb 89 04:38:47 PST
Message-Id: <8902091238.AA17692@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 9 Feb 89 07:37
To: x3j13@sail.stanford.edu
Subject: Issue: FONTS
Issue: FONTS
References: Working draft of the standard
Category: Clarifiaction
Edit history: 25-JAN-89, Version 1 by Chapman
7-FEB-89, Version 2 by Chapman (added discussion)
Problem Description:
The Common Lisp language description makes use of many commonly-used
English words for both their establish meanings and for special
purposes. Since the standard is required to be unambiguous,
a way was devised to distinguish an English word from special word of the same
name.
Proposal (FONTS:STANDARD)
Following is a list of the types of words that have been chosen for
special fonting and the name of the font used to represent each.
Word type Font name
Objects of type xxx (e.g. symbols) Slanted 10 point
Words in the glossary Italics
Tools in Chapters 6 and 7 Bold 9 point
Words in the keyword package defined by the standard Bold 9 point
Parameters supplied to functions/macros/special forms Sans serif 10 point
Rationale:
If the wording in the standard is unambiguous, users of the
standard will find it much easier to write portable code and
conforming implementations.
Current Practice:
CLtL uses fonting mainly for emphasis and for referring to
parameters in function descriptions.
Adoption Cost:
None.
Benefits:
The English descriptions in the standard will be less ambiguous.
Conversion Cost:
None.
Aesthetics:
The fonts have been reworked several times in order to improve
readability. It still requires some familiarity with the style
in order to discover its utility.
Discussion:
Steele says:
"Looks fine to me."
Rosenking says:
"Lets go with this proposal."
∂09-Feb-89 0444 X3J13-mailer Issue: TOC
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 9 Feb 89 04:44:38 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA17758; Thu, 9 Feb 89 04:42:48 PST
Message-Id: <8902091242.AA17758@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 9 Feb 89 07:40
To: x3j13@sail.stanford.edu
Subject: Issue: TOC
Issue: TOC
References: Working draft of the standard
Category: Editorial
Edit history: 25-JAN-89, Version 1 by Chapman
Problem Description:
The Table of Contents of the standard has changed several times since
the first one was introduced in November, 1987. One step in finalizing
the standard is to agree on the TOC.
Proposal (TOC:STANDARD)
Chapter 1. Introduction
CONTENTS
1.1 Scope, Purpose, and Application
1.2 Organization of the Document
1.3 Referenced Publications
1.4 Definitions
1.5 Compliance
1.6 Implementation-defined Features
Values
Results
Data Representation and Typing
Program and Control Structure
Comparisons
Numerical Calculations
User Interface
Input/Output
Compiling
Miscellaneous
Programming Environment
1.7 Language Extensions
1.8 Portability Issues
Chapter 2. Objects and Types
CONTENTS
2.1 Introduction
2.2 Types
Type Hierarchy and Relationships
Data Type Definition
Type Specifiers
2.3 Classes
Introduction to Classes
Metaclasses
Standard Metaclasses
Defining Classes
Creating Instances of Classes
Inheritance
Inheritance of Class Options
Examples
Determining the Class Precedence List
Topological Sorting
Examples
Redefining Classes
Modifying the Structure of Instances
Initializing Newly Added Local Slots
Customizing Class Redefinition
Extensions
Integrating Types and Classes
2.4 Slots
Introduction to Slots
Accessing Slots
Inheritance of Slots and Slot Options
2.5 Objects
Object Creation and Initialization
Initialization Arguments
Declaring the Validity of Initialization Arguments
Defaulting of Initialization Arguments
Rules for Initialization Arguments
Shared-Initialize
Initialize-Instance
Definitions of Make-Instance and Initialize-Instance
Changing the Class of an Instance
Modifying the Structure of the Instance
Initializing Newly Added Local Slots
Customizing the Change of Class of an Instance
Reinitializing an Instance
Customizing Reinitialization
Meta-Objects
Standard Meta-objects
Chapter 3. Object Syntax
CONTENTS
3.1 Character Reader
Reader Algorithm
Numbers as tokens
Symbols as tokens
Macro character collection
3.2 Object Syntax
Chapter 4. Evaluation and Compilation
CONTENTS
4.1 Evaluation Model
Introduction
Context and Environment
The Model
Form evaluation
Self-evaluating forms
Symbols as forms
Conses as forms
Return values
Shadowing
Extent
Generic Functions and Methods
Introduction to Generic Functions
Introduction to Methods
Agreement on Parameter Specializers and Qualifiers
Congruent Lambda-Lists for All Methods of a Generic Function
Keyword Arguments in Generic Functions and Methods
Method Selection and Combination
Determining the Effective Method
Standard Method Combination
Declarative Method Combination
Built-in Method Combination Types
Inheritance of Methods
Lambda-expressions
4.2 Compilation
Chapter 5. Other Topics
CONTENTS
5.1 Errors
Error Terminology
Condition System Concepts
Condtion System Data Types
Condtion System Operation
5.2 Input/Output
Files
Character and Binary Input/Output
Loading
5.3 Interface with the Programming Environment
Top level loop
Environment inquiry
Time
5.4 Generalized Reference
Chapter 6. Catalog of Tools (A-M)
A-F plus non-alphabetics
G-M
Chapter 7. Catalog of Tools (N-Z)
N-S
T-Z
Rationale:
The current TOC is a result of a year's worth of meetings and many
discussions of the editorial committee. The organization loosely
follows the CLOS chapters 1 and 2 organization by putting the
concepts first, and followed by an alphabetic listing of the
functions/macros/special forms/variables/constants.
The information that deals with data types is organized according to
the Lisp type hierarchy, and a listing of each language element
that is associated with that data type is located at the end
of each data type description in Chapter 2. These listings are
derived from the contents of the chapters in CLtL.
If we come to the conclusion that the standard should be shortened,
Chapters 6 and 7 can be modified to include fewer tools, and section
6.1 can be modified to reflect movement of some of the non-essential
parts of each description to an appendix.
Current Practice:
CLtL, as well as many other Lisp language specifications,
are organized by data types. The Lucid reference manual's chapters
each deal with a data type, but within those chapters, the information
is organized by concepts followed by an alphabetic listing of
language elements.
CLOS chapters 1 and 2 are organized by concepts first and an
alphabetic listing of language elements next.
Adoption Cost:
None.
Benefits:
The data type organization is useful for describing Lisp, and is therefore
used in chapters 2 and 3. However, categorizing
language elements by the data types they are meant to be used with imposes
an unnecessary structure on the document.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
∂09-Feb-89 0537 X3J13-mailer Issue: ERROR-TERMINOLOGY
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 9 Feb 89 05:36:52 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA19584; Thu, 9 Feb 89 05:35:16 PST
Message-Id: <8902091335.AA19584@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 9 Feb 89 07:56
To: x3j13@sail.stanford.edu
Subject: Issue: ERROR-TERMINOLOGY
Issue: ERROR-TERMINOLOGY
References: Chapter 5, Section 5.1, Working draft of the standard
CLOS Chapter 1
CLtL Chapter 1, Section 1.2.4
Condition System, Version 18
Category: Clarification
Edit history: 27-DEC-88, Version 1 by Chapman
31-JAN-89, Version 2 by Chapman
6-FEB-89, Version 3 by Chapman, RPG and Barmar comments included
8-FEB-89, Version 4 by Chapman, added more to Current Practice
Problem Description:
In CLtL, CLOS and the Condition System, similar but slightly
different language is used to describe
non-normal actions by CL operators. The X3J13 committee needs to
agree on a standard set of terms and their meanings.
Proposal (ERROR-TERMINOLOGY:STANDARD TERMS)
TERM MEANING (including CLtL -> standard conversion)
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
CONFORMING CODE (*) Code that adheres to the following requirements:
(1) Conforming code shall not use any constructions
that are prohibited by the standard.
(2) Conforming code shall not depend on extensions
included in an implementation.
SAFE CODE (*) Code processed with the SAFETY optimization at its
highest setting. SAFETY is a lexical property of code.
UNSAFE CODE (*) Code processed with lower safety levels.
Note: Unsafe code is not necesarily code that does not
do error checking. In many cases it may do less error
checking, but no guarantee that error checking will be
less in unsafe code is expressed or implied.
Implementations are permitted to treat all code as safe
code all the time, by simply ignoring the SAFETY
quality or the entire OPTIMIZE declaration.
IS SIGNALLED An error is signalled in both safe and unsafe code.
Conforming code may rely on the fact that the error
will be signalled in both safe and unsafe code.
Every implementation is required to detect the error
in both safe and unsafe code. For example, "an error
is signalled if UNEXPORT is given a symbol not accessible in
the current package."
SHOULD BE SIGNALLED An error will be signalled in safe code, and an error
might or might not be signalled in unsafe code.
Every implementation is required to detect the error at
least in safe code. When the error is not signalled,
the "consequences are undefined" (see below).
Note: The situation which has been identified as an error is
illegal in all implementations, but some implementations
do not actually detect the situation. Conforming code
known to be safe may rely on the error's being signalled.
For example, "an error should be signalled if ENDP is
given a non-list argument."
CONSEQUENCES ARE UNDEFINED The consequences are unpredictable. The consequences
may range from harmless to fatal. No conforming code can
depend on the results or effects. Conforming code must
treat the results and effects as unpredictable.
In places where the words "must", "must not" or "may
not" are used, then "the consequences are undefined"
if the stated requirement is not met, and no specific
consequence is explicitly stated.
For example: CLtL currently says: (page 69) "Once a
name has been declared by DEFCONSTANT to be constant,
any further assignment or binding of that special
variable is an error." This statement would be
transformed to: "Once a name has been declared by
DEFCONSTANT to be constant, any further assignment or
binding of that special variable has undefined consequences."
Note: A result or effect is unpredictable if it might
vary among implementations or separate invocations
within a single implementation. Theh definition of
a harmless effect is difficult to specify precisely.
It is intended that printing error messages on the
stream *ERROR-OUTPUT* or modifying implementation
data during normal operations are harmless. Allocating
storage, invoking a garbage collector, and re-hashing
are prototypicl examples of things that have harmless
effects. In general, an effect is harmless is if does
not cause the implementation to halt or otherwise enter
an inconsistent state.
An effect is fatal if it causes the implementation to
halt or destroys user, implementation, or system data.
For example, leaving the file system in an inconsistent
state is considered fatal. Other unpredictable effects
include entering the debugger or destroying a user data
structure.
If code depends on a harmless effect, then the result
can be fatal. This is why conforming code may not
depend on such effects.
Implementations are permitted to do anything in this
situation.
RETURN VALUES ARE UNDEFINED Only the number and nature of the return values
of a construct are not well defined but any side-effect
and transfer-of-control behavior is well defined. For
example, if the return values of some function F are
undefined, then an expression such as
(length (list (F))) is still well-defined because it
does not rely on any particular aspect of the value or
values returned by F.
CONSEQUENCES ARE UNSPECIFIED The consequences are unpredictable but harmless.
Implementations are permitted to specify the
consequences of this situation. No conforming code may
depend on the results or effects of this situation,
and all conforming code is required to treat the results
and effects of this situation as unpredictable but
harmless. For example, ``the consequences of the garbage
collector when invoked are unspecified.''
IMPLEMENTATIONS MAY BE EXTENDED An implementation is free to treat
the situation in ANY ONE of the following ways:
(1)When the situation occurs, an error is signalled at
least in safe code,
OR
(2)When the situation occurs, the "consequences are
undefined",
OR
(3)When the situation occurs, the consequences are
defined.
Also, no conforming code can depend on the results or
effects of this situation, and all conforming code must
treat the results and effects of the situation as
undefined. Implementations are permitted to do anything
in this situation. For example, "implementations may be
extended to define other type specifiers to have a
corresponding class."
Note: Users should consult the implementation reference
manual to determine the results or effects of this
situation, but should never depend on the results or
effects of this situation in code to be run on other
implementations.
FREE TO EXTEND THE SYNTAX Implementations are permitted to define unambiguous
extensions to the syntax of the construct being
described. No conforming code can depend on this
extension. All conforming code is required to treat
the syntax as meaningless. The standard may disallow
certain extensions while allowing others. For example,
"no implementation is free to extend the syntax of
DEFCLASS."
WARNING IS ISSUED A warning is issued, as described in WARN, in both safe
and unsafe code and when the situation is detected by
the compiler. Conforming code may rely on the fact
that a warning will be issued in both safe and unsafe
code and when the situation is detected by the compiler.
Every implementation is required to detect this
situation in both safe and unsafe code and when the
situation is detected by the compiler. The presence of
a warning will in no way alter the value returned by
the form which caused the situation to occur. For
example, "a warning is issued by the compiler if a
declaration specifier is not one of those defined in
Chapter 9 of CLtL and has not been declared in a
DECLARATION declaration."
WARNING SHOULD BE ISSUED A warning may be issued. Conforming code may not rely
on the fact that a warning will be issued. If the
situation is detected by the compiler, a warning may or
may not be issued, depending on the implementation.
The presence of a warning will in no way alter the
value returned by the form which caused the situation
to occur. For example, (paraphrasing from CLtL, p. 160)
"a warning should be issued by a compiler if a variable
declared to be ignored is ever referred to or is also
declared special, or if a variable is lexical, never
referred to, and not declared to be ignored."
(*) means this term is used to define other terms in this proposal,
not explicitly used in the standard.
Rationale:
For the standard to be an exact specification, terminology must be
defined and agreed upon.
Current Practice:
CLtL uses "is signalled", "should be signalled", "is an error",
"a warning is issued", and "a warning should be issued".
It also uses "is not permitted", "is desireable that", "is not legitimate",
"is illegal", and "should be" (not associated with "signalled"),
"must be", "must not", as well as other such terms.
The definition of "is an error" in CLtL has come to mean "is
allowed" in places where implementations typically extend the language.
CLOS and the Condition System use "is undefined" "is unspecified",
"may be extended", "free to extend the syntax", and "return values are
undefined".
Adoption Cost:
The cost of adopting this terminology will be mostly associated with the
change from "is an error" to some other more specific terminology
from the above list (typically "is an error" -> "is undefined").
Benefits:
Specific terminology will disambiguate function descriptions which
will save implementor's time and decrease user frustration. Users should
be able to write more portable code if the specification is exact.
Conversion Cost:
See Adoption Cost.
Aesthetics:
None.
Discussion:
Barmar comments:
"... I still hate giving the synonyms "undefined" and "unspecified"
different meanings in the standard, but I've given up on that issue."
RPG responds:
"This point is important. In looking over all intended uses of one over the
other, almost all the time we will be saying that something is undefined
when we want people to not use it because the effects could get you, while
we will be saying that values are unspecified. Other times we will be
saying that whether or not something happens is unspecified.
I doubt we will be able to settle this without fine tuning as we see
the effects in the document."
∂09-Feb-89 0831 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Hong Kong International Computer Conference
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Feb 89 08:31:46 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA11308; Thu, 9 Feb 89 08:27:29 -0800
Message-Id: <8902091627.AA11308@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Thu, 9 Feb 89 08:30:09 PST
Received: by BYUADMIN (Mailer R2.01A) id 8607; Thu, 09 Feb 89 09:28:35 MST
Date: Thu, 9 Feb 89 09:07:54 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Robert A. Flavin" <RIBO%YKTVMH.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Robert A. Flavin" <RIBO%YKTVMH.BITNET@forsythe.stanford.edu>
Subject: Hong Kong International Computer Conference
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
HONG KONG INTERNATIONAL COMPUTER CONFERENCE
The Hong Kong International Computer Conference will be held
April 10-14, 1989. The theme of this conference will be
Information Technology Directions for the 90's. The
conference is organized by the Hong Kong Computer Society and
speakers will include:
Dr. John Connolly
Director Supercomputer Institute, University of Kentucky
Mr. Sam Fuller
Vice President, Digital Equipment Corporation
Dr. Paul Horn
Director of Physical Sciences, IBM Research Division
Dr. Charles Kao
Vice Chancellor, The Chinese University of Hong Kong
For more information please contact:
Mr. George Eggert
312-299-4227 or 312-299-4270
FAX number: 312-299-4280
∂09-Feb-89 0928 X3J13-mailer Re: Issue: ERROR-TERMINOLOGY
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 9 Feb 89 09:28:02 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA18047; Thu, 9 Feb 89 09:28:49 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA17625; Thu, 9 Feb 89 09:25:28 PST
Received: by clam.sun.com (4.0/SMI-4.0)
id AA18377; Thu, 9 Feb 89 09:28:22 PST
Date: Thu, 9 Feb 89 09:28:22 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8902091728.AA18377@clam.sun.com>
To: chapman%aitg.DEC@decwrl.dec.com, x3j13@sail.stanford.edu
Subject: Re: Issue: ERROR-TERMINOLOGY
Regarding "CONSEQUENCES ARE UNSPECIFIED": I believe that attempts to
use this concept will just get into trouble.
(The problems I see are with "unspecified side-effects". Unspecified
values are OK.) For one thing, how are we to decide what effects
are harmless? Is changing value of *READ-BASE* harmless? That depends
on the program. Is changing the alue of *READ-BASE* to NIL harmless?
And so on.
The example statement that ``the consequences of the garbage collector
when invoked are unspecified'' has some interest. Perhaps there is an,
exception or two, but in general there should be *no* side-effects from
running the garbage collector, at least none visible to a Lisp program.
It can make sense to specify that certain actions may or may not
have certain side effects, or to specify a range of outcomes, but
that requires a statement in each case. Various cleanup proposals
with "EXPLICITLY-VAGUE" somewhere in their names are of this kind.
My proposal is that the concept and term "CONSEQUENCES ARE UNSPECIFIED"
be deleted from the Common Lisp standard. Any existing uses will have
to be changed. Usually some "explicitly vague" statement is appropriate.
∂09-Feb-89 0959 X3J13-mailer Re: Issue: ERROR-TERMINOLOGY
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 9 Feb 89 09:58:54 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Thu, 9 Feb 89 12:28:54 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Thu, 9 Feb 89 12:54:29 EST
Date: Thu, 9 Feb 89 12:56 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Re: Issue: ERROR-TERMINOLOGY
To: Cris Perdue <cperdue@sun.com>
Cc: chapman%aitg.DEC@decwrl.dec.com, x3j13@sail.stanford.edu
In-Reply-To: <8902091728.AA18377@clam.sun.com>
Message-Id: <19890209175604.9.BARMAR@OCCAM.THINK.COM>
Date: Thu, 9 Feb 89 09:28:22 PST
From: cperdue@sun.com (Cris Perdue)
Regarding "CONSEQUENCES ARE UNSPECIFIED": I believe that attempts to
use this concept will just get into trouble.
(The problems I see are with "unspecified side-effects". Unspecified
values are OK.)
That's why they are categorized differently. We all recognize that
unspecified values is an easy problem.
For one thing, how are we to decide what effects
are harmless? Is changing value of *READ-BASE* harmless? That depends
on the program. Is changing the alue of *READ-BASE* to NIL harmless?
And so on.
Didn't we go through this once before. The proposal has an informal
definition of "harmless", and that's the best we're going to get. By
its definition, setting the value of *READ-BASE* to any of its allowable
values is harmless; the results of a program may change, but they are
predicted by the language definition. The consequences of setting it to
something that isn't a fixnum from 2 to 36 is undefined, in my opinion,
so it isn't necessarily harmless.
The example statement that ``the consequences of the garbage collector
when invoked are unspecified'' has some interest. Perhaps there is an,
exception or two, but in general there should be *no* side-effects from
running the garbage collector, at least none visible to a Lisp program.
Here are some results of the garbage collector I'd expect in typical
Lisp systems: the output of (ROOM) will change, the order of entries in
EQ/EQL hash tables will change.
It can make sense to specify that certain actions may or may not
have certain side effects, or to specify a range of outcomes, but
that requires a statement in each case. Various cleanup proposals
with "EXPLICITLY-VAGUE" somewhere in their names are of this kind.
My proposal is that the concept and term "CONSEQUENCES ARE UNSPECIFIED"
be deleted from the Common Lisp standard. Any existing uses will have
to be changed. Usually some "explicitly vague" statement is appropriate.
Kathy, are there any uses of it yet? Have you started converting uses
of "is an error" to the new terminology? I think the DEFPACKAGE
proposal may have used the word "unspecified" when describing the
results of executing a DEFPACKAGE for an existing package but with a
conflicting definition, but I don't know whether the author of the
Cleanup proposal intended to be using the new terminology or was just
using the word informally.
barmar
∂09-Feb-89 1003 emma@csli.Stanford.EDU CSLI Calendar, 9 February, 4:15
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Feb 89 10:03:01 PST
Received: by csli.Stanford.EDU (4.0/inc-1.0)
id AA17167; Thu, 9 Feb 89 09:30:22 PST
Date: Thu, 9 Feb 89 09:30:22 PST
From: emma@csli.Stanford.EDU (Emma Pease)
Message-Id: <8902091730.AA17167@csli.Stanford.EDU>
To: friends@csli.Stanford.EDU
Subject: CSLI Calendar, 9 February, 4:15
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
9 February 1989 Stanford Vol. 4, No. 15
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR NEXT THURSDAY, 16 February 1989
12 noon TINLunch
Cordura Hall Defeasible Reasoning and Nonmonotonic
Conference Room (and worse) Inference Relations:
A Little Philosophy; A Little AI; A Little Logic
David Israel
(israel@ai.sri.com)
Abstract below
2:15 p.m. CSLI Seminar
Cordura Hall Overview of the German Research Center for AI
Conference Room Gerhard Barth
German Research Center for AI
3:30 p.m. Tea
Ventura Hall
____________
NEXT WEEK'S TINLUNCH
Defeasible Reasoning and Nonmonotonic
(and worse) Inference Relations:
A Little Philosophy; A Little AI; A Little Logic
David Israel
16 February
Starting about a decade ago, researchers in Artificial Intelligence
began to formalize certain oddly behaved, in particular nonmonotonic,
inference patterns. Some of these, e.g., Reiter's logic for default
reasoning, modeled features of actually existing computational
systems; others, such as circumscription, were presented as capturing
important features of actual, human common-sense reasoning. In both
kinds of case, the phenomenon under consideration has something to do
with what philosophers have called `defeasible reasoning.'
The latter will be very briefly characterized. We shall then move
on to recent attempts by logicians Dov Gabbay, on the one hand, and
David Makinson, on the other, to give abstract axiomatic accounts of a
variety of these nonmonotonic inference relations. These will be
described and some important results mentioned. A few questions will
be raised about what such inference relations have to do with
defeasible reasoning. `Many' fewer answers will be suggested.
____________
LINGUISTICS DEPARTMENT COLLOQUIUM
A Typology of Possible Morphophonological Change
Bill J. Darden
University of Chicago
Friday, 17 February, 3:15
Cordura Conference Room
____________
COMMONSENSE AND NONMONOTONIC REASONING SEMINAR
Circumscribing Equality
Peter K. Rathmann
Stanford University
Marianne Winslett
University of Illinois
Monday, 13 February, 3:15pm
MJH 301
One important facet of common-sense reasoning is the ability to draw
default conclusions about the state of the world, so that one can, for
example, assume that a given bird flies in the absence of information
to the contrary. A black mark against the circumscriptive approach to
common-sense reasoning has been its inability to produce default
conclusions about equality; for example, one cannot in general
tentatively conclude that President(USA) $\not =$ Fido using
circumscription. In this talk we will give a model theory and
second-order axiom for circumscribing equality.
-----------
SYMBOLIC SYSTEMS FORUM
Semiotics
David Wellbery
German Studies
Friday, 17 February, 3:15
Room 60:61G
David Wellbery will explain why symbolic systems should consider the
humanities as a part of its major. There has been much work on
symbols, symbolism, meaning, interpretation, and much more in the
humanities (principally semiotics, literary theory, and symbolic
anthropology), which researchers and students in symbolic systems
could use and might miss otherwise. On the other hand, as in every
case of collaboration, these humanities disciplines also stand to gain
great benefit from ideas within technical symbolic systems. In this
vein, Professor Wellbery hopes to hold an informal discussion in which
he will present some ideas about semiotics and attempt to justify
collaboration.
∂09-Feb-89 1008 X3J13-mailer Issue: ERROR-TERMINOLOGY
To: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Many people seem to believe that saying something is harmless is a useless
thing to say in the standard. If we were to drop this term, then every
time we are ``explicitly vague'' a valid possibility is that a fatal error
can occur. How is it any better to say that what happens when some
operation happens is ``explictly vague''? Also, to try to enumerate a
a set of alternatives presumes we are able to forsee all implementation
technologies, which is simply not possible.
To be more explicit, it is valid to specify what can happen if an illegal
operation is performed. If we are not able to list all such effects, users
can have two questions: Do *I* have to worry about detecting that my
program is about to perform this action because my run will be trashed, or
can I simply let it happen without worry? ``Undefined'' and
``unspecified'' are the terms that anwer these questions.
People have asked what happens if *read-base* is changed, is that
harmless? Well, for one thing changing that is never claimed to be among
the things whose effects is unspecified. Second, the other clauses in the
definition must be read at the same time as you read the one about
harmless effects: programs that depend on the effects are not conforming.
Because *read-base* is something explicitly to depend upon, any change to
it behind your back is not harmless.
Certainly in the definition of harmless effects we can explicitly
rule out unspecified changes to things like *read-base* (we can enumerate
them if you like).
People seem to feel that if we cannot with mathematical precision define a
term we should not use it. The attitude to head in that direction is good,
but if you want to go all the way, we are sadly many years away from a
suitable draft. When I read the current draft (and CLtL for that matter) I
find that almost every paragraph requires my detailed knowledge of Lisp
(and sometimes Lisp implementation technology) to understand. Therefore,
we cannot hope for a self-contained document.
Cris writes:
``Perhaps there is an, exception or two, but in general there should be
*no* side-effects from running the garbage collector, at least none
visible to a Lisp program.''
One effect that can be detected is the time it takes. In a realtime system,
that can be fatal. This is perhaps the most serious effect whose harmlessness
is debatable.
Finally, we all depend on the implementors to implement harmless effects
all the time. I think it is useful to be able to specify which operations
are allowed to go boom and which must not for their benefit.
I think in Hawaii we agreed informally to look at the draft when it has
more of the uses of these terms in place to determine whether their meanings
are adequate or whether we should drop some or replace them. Let's stick
with that.
-rpg-
∂09-Feb-89 1059 X3J13-mailer Re: Issue: ERROR-TERMINOLOGY
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 9 Feb 89 10:59:03 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA20436; Thu, 9 Feb 89 11:00:06 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA23021; Thu, 9 Feb 89 10:56:46 PST
Received: by clam.sun.com (4.0/SMI-4.0)
id AA18461; Thu, 9 Feb 89 10:59:45 PST
Date: Thu, 9 Feb 89 10:59:45 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8902091859.AA18461@clam.sun.com>
To: RPG@SAIL.Stanford.EDU, x3j13@SAIL.Stanford.EDU
Subject: Re: Issue: ERROR-TERMINOLOGY
Many people seem to believe that saying something is harmless is a useless
thing to say in the standard. If we were to drop this term, then every
time we are ``explicitly vague'' a valid possibility is that a fatal error
can occur. How is it any better to say that what happens when some
operation happens is ``explictly vague''? Also, to try to enumerate a
a set of alternatives presumes we are able to forsee all implementation
technologies, which is simply not possible.
REMF-DESTRUCTION-UNSPECIFIED:EXPLICITLY-VAGUE, which passed at
the last meeting, I think is a good example of a form of specification
that can be successful. It prescribes a set of things that destructive
operations can do without pinning itself down to just one alternative.
People have asked what happens if *read-base* is changed, is that
harmless? Well, for one thing changing that is never claimed to be among
the things whose effects is unspecified.
I was trying to ask the question whether changing *read-base* would
be a "harmless" side-effect for some other operation, such as running
the garbage collector. I wasn't meaning to talk about unspecified effects
of an explicit (incf *read-base*).
∂09-Feb-89 1059 snoeyink@polya.Stanford.EDU [irani@ernie.Berkeley.EDU: BATS Correction]
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Feb 89 10:59:15 PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA17372; Thu, 9 Feb 89 10:54:03 -0800
Date: Thu, 9 Feb 89 10:54:03 -0800
From: Jack Snoeyink <snoeyink@polya.Stanford.EDU>
Message-Id: <8902091854.AA17372@polya.Stanford.EDU>
To: aflb-local@polya.Stanford.EDU
Subject: [irani@ernie.Berkeley.EDU: BATS Correction]
Date: Wed, 8 Feb 89 16:59:24 -0800
From: irani@ernie.Berkeley.EDU (Sandy Irani)
Subject: BATS Correction
Please note that the last two talks were originally listed
for 12:10 and 1:10. They will be given at 1:10 and 2:10.
BATS will be on Friday February 10, in Sibley Auditorium.
Lunch will be served in Bechtel 120A & B at 12:00.
The schedule is as follows:
10:10 Dorit Hochbaum (Berkeley): The Complexity of Integer Nonlinear
Optimization over Linear Polytopes
11:10 Peter Gacs (Boston University and IBM Almaden Research Center)
Self-correcting and self-organizing cellular arrays
1:10 Ashok Subramanian (Stanford) The Complexity of Circuit
Value and Network Stability
2:10 Seffi Naor (Stabford) Maximum Flow in Networks with Many
Sources and Sinks
∂09-Feb-89 1248 lansky@ai.sri.com AI-RR Seminar -- TUESDAY (Valentine's Day) -- 2pm -- W.Zadrozny
Received: from Warbucks.AI.SRI.COM ([128.18.3.1]) by SAIL.Stanford.EDU with TCP; 9 Feb 89 12:48:03 PST
Received: from venice.ai.sri.com by Warbucks.AI.SRI.COM with INTERNET ;
Thu, 9 Feb 89 12:30:46 PST
Received: by venice.ai.sri.com (3.2/4.16)
id AA16949 for planlunch@ai.sri.com; Thu, 9 Feb 89 12:31:01 PST
Date: Thu, 9 Feb 89 12:31:01 PST
From: lansky@Warbucks.AI.SRI.COM (Amy Lansky)
Message-Id: <8902092031.AA16949@venice.ai.sri.com>
To: planlunch@Warbucks.AI.SRI.COM
Subject: AI-RR Seminar -- TUESDAY (Valentine's Day) -- 2pm -- W.Zadrozny
VISITORS: Please arrive 5 minutes early so that you can be escorted up
from the E-building receptionist's desk. Thanks!
-----------------------------------------------------------------------
A THREE-LEVEL THEORY OF REASONING
Wlodek Zadrozny (WLODZ@IBM.COM)
IBM T.J.Watson Research Center
2:00 PM, TUESDAY, February 14
SRI International, Building E, Room EJ228
In this talk we present a three-level theory of reasoning; we also
sketch some applications to semantics of natural language. In this
theory knowledge bases containing defaults are understood not as sets
of formulas (rules and facts) but as collections of partially ordered
theories. As a result of this shift of perspective we obtain a rather
natural logical system in which priorities in interpretation of
predicates are the source of nonmonotonicity in reasoning. In our
formalization, the usual, two-part logical structures, consisting of a
metalevel and an object level, are augmented by a third level -- a
referential level. The referential level is a partially ordered
collection of default theories -- it contains a more permanent part of
a knowledge base; current situations are described on the obect level;
the metalevel is a place for rules that can eliminate some of the
models permitted by the object level and the referential level. We
also prove basic results about derivability in this system. Finally,
commonsense conclusions of an object theory can be identified with
sentences true in a set of models specified by this three-level
semantics.
∂10-Feb-89 0819 HEMENWAY@Score.Stanford.EDU Batch 3 folders
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Feb 89 08:19:02 PST
Date: Fri 10 Feb 89 08:16:11-PST
From: Sharon Hemenway <HEMENWAY@Score.Stanford.EDU>
Subject: Batch 3 folders
To: phd-adm@Score.Stanford.EDU
Reply-To: Hemenway@Score.Stanford.EDU
Message-ID: <12469581358.19.HEMENWAY@Score.Stanford.EDU>
You will most likely notice that a few of the folders you have in this
batch are missing one letter of recommendation. We do this in this
batch so that these applicants, some of whom are quite strong, can get
two readings. Although I realize that this may make it even more
difficult for you to effectively rate them, it seems unfair to penalize
the students for a recalcitrant recommender!
Sharon
P.S. I'll be back in touch later today about the Round 1 meeting.
-------
∂10-Feb-89 1018 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Disk Space problems on Polya
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Feb 89 10:18:26 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 10 Feb 89 10:14:33-PST
Message-ID: <Ln91b@SAIL.Stanford.EDU>
Date: 10 Feb 89 1016 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Disk Space problems on Polya
To: ball@POLYA.Stanford.EDU, farhad@POLYA.Stanford.EDU,
grossman@POLYA.Stanford.EDU, wheaton@ATHENA.Stanford.EDU
CC: faculty@SCORE.STANFORD.EDU
The other day I saw a system message on Polya that indicated that there
was a disk space shortage on /u2 on Polya and users were requested to
reduce their disk usage. Requesting users to reduce their disk usage is a
*bad* idea. Here are several reasons why:
1. If there is an imbalance of users on /u1 and /u2, some can be shifted
from one disk to another to temporary alleviate the shortage.
2. I think we should be in the business of encouraging more computer usage
not less. If more people use disk storage, we can lower the rates for
disk storage and that will encourage even more use.
3. Disk drives are cheap. If we are running out of disk storage, put
another disk drive on Polya.
Please post another system message *encouraging* people to use as much
disk space as they need. Tell them we can buy more disk drives if we need
them. Don't send out shortsighted messages that are tantamount to
shooting ourselves in the foot. Encourage computer usage! It's the only
way to pay for those beasts.
Arthur
∂10-Feb-89 1031 STAGER@Score.Stanford.EDU 1989/90 Courses and Degrees
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Feb 89 10:31:34 PST
Date: Fri 10 Feb 89 10:27:32-PST
From: Claire Stager <STAGER@Score.Stanford.EDU>
Subject: 1989/90 Courses and Degrees
To: faculty@Score.Stanford.EDU
cc: stager@Score.Stanford.EDU
Office: CS-TAC 29, 723-6094
Message-ID: <12469605267.21.STAGER@Score.Stanford.EDU>
I'm sending out memos and course descriptions today, via courier, asking for
your revisions and input for next year's Courses and Degrees Bulletin.
Please note the deadline--FEBRUARY 24--by which I need to hear from you.
Thanks.
Claire
-------
∂10-Feb-89 1038 @Score.Stanford.EDU:farhad@polya.Stanford.EDU Re: Disk Space problems on Polya
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Feb 89 10:37:16 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 10 Feb 89 10:32:14-PST
Received: from LOCALHOST by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA13904; Fri, 10 Feb 89 10:30:03 -0800
Message-Id: <8902101830.AA13904@polya.Stanford.EDU>
To: Arthur Keller <ARK@SAIL.Stanford.EDU>
Cc: ball@POLYA.Stanford.EDU, farhad@POLYA.Stanford.EDU,
grossman@POLYA.Stanford.EDU, wheaton@ATHENA.Stanford.EDU,
faculty@SCORE.STANFORD.EDU, farhad@polya.Stanford.EDU
Subject: Re: Disk Space problems on Polya
In-Reply-To: Your message of 10 Feb 89 10:16:00 -0800.
<Ln91b@SAIL.Stanford.EDU>
Date: Fri, 10 Feb 89 10:30:02 -0800
From: farhad@polya.Stanford.EDU
+------------------------------
| The other day I saw a system message on Polya that indicated that there
| was a disk space shortage on /u2 on Polya and users were requested to
| reduce their disk usage. Requesting users to reduce their disk usage is a
| *bad* idea. Here are several reasons why:
| 1. If there is an imbalance of users on /u1 and /u2, some can be shifted
| from one disk to another to temporary alleviate the shortage.
| 2. I think we should be in the business of encouraging more computer usage
| not less. If more people use disk storage, we can lower the rates for
| disk storage and that will encourage even more use.
| 3. Disk drives are cheap. If we are running out of disk storage, put
| another disk drive on Polya.
| Please post another system message *encouraging* people to use as much
| disk space as they need. Tell them we can buy more disk drives if we need
| them. Don't send out shortsighted messages that are tantamount to
| shooting ourselves in the foot. Encourage computer usage! It's the only
| way to pay for those beasts.
| Arthur
+------------------------------
The message I send was something I inhereted while I was working at
Berkeley and I underestand it should not have been posted. But it
seemed a very good solution at that time when /u1 was 100% full and
nobody could do anything. Moving users around was my second choice
but I found the user who filled it up and he is eliminated.
I left a message on /etc/motd that everybody will see it when they
login to the system:
Polya: Disk Space Shortage is OVER. Feel free to use them.
Farhad
∂10-Feb-89 1041 @Score.Stanford.EDU:ball@polya.Stanford.EDU Disk Space problems on Polya
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Feb 89 10:41:41 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 10 Feb 89 10:32:50-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA13973; Fri, 10 Feb 89 10:30:56 -0800
Date: Fri, 10 Feb 89 10:30:56 -0800
From: Jim Ball <ball@polya.Stanford.EDU>
Message-Id: <8902101830.AA13973@polya.Stanford.EDU>
To: ARK@SAIL.Stanford.EDU
Cc: farhad@POLYA.Stanford.EDU, grossman@POLYA.Stanford.EDU,
wheaton@ATHENA.Stanford.EDU, faculty@SCORE.STANFORD.EDU
In-Reply-To: Arthur Keller's message of 10 Feb 89 1016 PST <Ln91b@SAIL.Stanford.EDU>
Subject: Disk Space problems on Polya
Arthur,
You're absolutely correct. We have had some discussion here at CSD-CF
regarding this type of message. I think it is now clear to everyone that
we really don't want to discourage usage.
Thanks for the comments.
-Jim
∂10-Feb-89 1055 LOGMTC-mailer Seminar in Logic
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Feb 89 10:55:07 PST
Received: by csli.Stanford.EDU (4.0/inc-1.0)
id AA21052; Fri, 10 Feb 89 10:53:18 PST
Date: Fri 10 Feb 89 10:53:17-PST
From: Sol Feferman <SF@CSLI.Stanford.EDU>
Subject: Seminar in Logic
To: Logic@csli.Stanford.EDU
Message-Id: <603139997.0.SF@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
Seminar in Logic
Speaker: Prof. I. Katznelson, Dept. of Mathematics, Stanford
Title: "Semigroups, idempotents and Ramsey theory"
Time: Mon. Feb. 13, 4:15-5:30
Place: Room 383-N, 3d floor lounge, Math Corner, Stanford
Note: This is the first of two talks, at a different time and place
than usual schedule for the seminar. The second talk will be on Tues
Feb 21, at 4:15-5:30 in Room 381-T.
Abstract: Some recent results in the line of the theorems of van der
Waerden, Hales-Jewett, Carlson-Simpson etc. will be presented in an
introductory exposition. The methods use the existence of idempotents
in compact semigroups, and are thus an example of the use of non-constructive
methods to obtain combinatorial results.
S. Feferman
-------
∂10-Feb-89 1449 HEMENWAY@Score.Stanford.EDU Round 1 Meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Feb 89 14:49:19 PST
Date: Fri 10 Feb 89 14:47:00-PST
From: Sharon Hemenway <HEMENWAY@Score.Stanford.EDU>
Subject: Round 1 Meeting
To: phd-adm@Score.Stanford.EDU
Reply-To: Hemenway@Score.Stanford.EDU
Message-ID: <12469652502.38.HEMENWAY@Score.Stanford.EDU>
There was, of course, no overwhelming concensus of the best time for
the meeting but the lesser of all evils seems to fall on Monday,
Feb. 20 at 3:00. We'll meet in the same room - MJH 252.
Right now, the only people who have indicated to me that they cannot
meet at this time are Gene Golub and Bob Moore. If this is now a
bad time for anyone else, please let me know as soon as possible.
I'll see you all on President's Day - February 20 at 3:00.
Sharon
-------
∂11-Feb-89 1339 @polya.Stanford.EDU:tah@linz Faculty candidate
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Feb 89 13:39:47 PST
Received: from linz.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA04057; Sat, 11 Feb 89 13:34:35 -0800
Received: by linz.stanford.edu (5.59/25-eef) id AA07172; Sat, 11 Feb 89 13:30:31 PDT
Message-Id: <8902112130.AA07172@linz.stanford.edu>
To: thcom@sail, aflb-all@polya
Subject: Faculty candidate
Reply-To: tah@cs.stanford.edu
Date: 11 Feb 89 13:30:27 PST (Sat)
From: Tom Henzinger <tah@linz>
Mauricio Karchmer from Toronto will be visiting on Monday and Tuesday,
Feb. 12-13. If you want to join him for lunch or dinner on either day,
or talk with him, please send me a message. -t
∂12-Feb-89 1619 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu Calendar Advisory
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Feb 89 16:19:13 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Sun 12 Feb 89 16:17:06-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA02719; Sun, 12 Feb 89 16:17:10 PDT
Date: Sun, 12 Feb 89 16:17:10 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8902130017.AA02719@Tenaya.stanford.edu>
To: ac@score
Subject: Calendar Advisory
The "theory" search committee has requested a faculty meeting where
they can present their recommendations about new faculty candidates.
Because these candidates are super outstanding, they have offers from
other places, and we must try to reach a decision soon if we are to be
in the running. Therefore I would appreciate it if all could free
their calendars for Tuesday afternoon, February 21 for a faculty
meeting. The exact time of this meeting has yet to be pinned down.
(I hope to do this tomorrow.) Between now (that is, 2/13) and the
meeting the files and letters on the candidates to be recommended will
be available for your study in Joyce Chandler's office. Please do
look these over so our discussion at the meeting can proceed
expeditiously.
I regard our decisions about how to strengthen Stanford's theoretical
computer science as extremely important, so I am hopeful that all
will be able to arrange that Tuesday so that they will not be
constrained by time pressures. Thanks, -Nils
∂13-Feb-89 0023 barwise@russell.Stanford.EDU Question from student
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Feb 89 00:23:21 PST
Received: from [127.0.0.1] by russell.Stanford.EDU (4.0/inc-1.0)
id AA14924; Sun, 12 Feb 89 14:38:13 PST
Message-Id: <8902122238.AA14924@russell.Stanford.EDU>
To: ssp-faculty@russell.Stanford.EDU
Cc: weiss@portia.stanford.edu
Subject: Question from student
Date: Sun, 12 Feb 89 14:36:41 PST
From: Jon Barwise <barwise@russell.Stanford.EDU>
Barbara, Dave and other ssp faculty,
Here is a question from a student that I can't answer. Can
any of you. -Jon
------- Forwarded Message
Return-Path: weiss@Portia.stanford.edu
Return-Path: <weiss@Portia.stanford.edu>
Received: from Portia.stanford.edu ([36.21.0.69]) by russell.Stanford.EDU (4.0/inc-1.0)
id AA05347; Sun, 12 Feb 89 13:54:57 PST
Received: by Portia.stanford.edu (5.59/25-eef) id AA01215; Sun, 12 Feb 89 13:49:57 PDT
Message-Id: <8902122149.AA01215@Portia.stanford.edu>
Date: 12 Feb 1989 1349-PST (Sunday)
>From: Scott Weiss <weiss@Portia.stanford.edu>
To: barwise@russell
Cc:
Subject: Decision theory and computer science
Professor Barwise,
I was in your class (Philosophy 159) last quarter, and I was
wondering if you might know of anyone that I would be able to work
with/under for a research idea that I have been wondering about.
It involves dyslexia, with color as a device to mask its
symptoms (based on research by Helen Irlen in Long Beach). I'd like
to develop some software that walks a person through some color
trials, but with some logic behind it; to actually make a guess as to
the next most valid color choice, based on user input. I hope to use
the Macintosh II as a color device, with its friendly user-interface.
The most important part of the research is Helen Irlen's
findings, which I could apply to a computer, but I feel that the work
would go much better with a "logical" foundation.
Your thoughts would be greatly appreciated.
Scott D. Weiss
------- End of Forwarded Message
∂13-Feb-89 0750 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Tomorrow's Faculty Lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Feb 89 07:50:47 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 13 Feb 89 07:47:41-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA24042; Mon, 13 Feb 89 07:45:38 -0800
Date: Mon, 13 Feb 1989 7:45:36 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, bureaucrats@score, staff-rep@score
Subject: Tomorrow's Faculty Lunch
Message-Id: <CMM.0.87.603387936.chandler@polya.stanford.edu>
Just a reminder.....tomorrow's faculty lunch, in MJH-146 at 12:15......more
about the PhD program. See you there!
∂13-Feb-89 1018 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Forsythe Lectures
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Feb 89 10:18:41 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 13 Feb 89 10:06:39-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA29170; Mon, 13 Feb 89 10:04:37 -0800
Date: Mon, 13 Feb 1989 10:04:31 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: csd-list@score
Subject: Forsythe Lectures
Message-Id: <CMM.0.87.603396271.chandler@polya.stanford.edu>
Professor Ruzena Bajcsy, Chair of the Computer and Information Science
Department at the University of Pennsylvania is at Stanford to deliver the
George and Sandra Forsythe Memorial Lectures. The first lecture will be
delivered tonight at 7:30 in Fairchild Auditorium (which is just southwest of
Stanford Medical Center off Campus Drive). The title of tonight's lecture is
"Perception via Active Exploration".
A reception will follow in the Foyer of Fairchild Auditorium.
Abstract:
Following Gibson's perceptual theory, we shall demonstrate in the context of
machine perception that a machine should look (and not oly see) and feel (and
not only touch). That is, a perceiving system actively seeks information.
Also, perceptual exploratory procedures must be bulit in in order for a robot
to explore, manipulate, and move around in an unknown environment. Concrete
examples from a laboratory environment will be presented as an existence
proof of this theory of machine perception.
∂13-Feb-89 1141 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu faculty meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Feb 89 11:40:37 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 13 Feb 89 11:33:14-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA03274; Mon, 13 Feb 89 11:21:25 PDT
Date: Mon, 13 Feb 89 11:21:25 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8902131921.AA03274@Tenaya.stanford.edu>
To: ac@score
Subject: faculty meeting
We will be having a faculty meeting to discuss three potential CS
theory candidates on Tuesday, February 21 at 4:15 pm in MJH 146.
Please be prepared to stay 'til 6, but if everyone reads the vitaes
ahead of time (see Joyce Chandler), then we ought to be able to finish
earlier. I'm sorry about the short notice, but departments on the
move need to have a quick reaction capability! (Quick but
thoughtful!!)
John McCarthy may also want to bring up a resolution to be taken
to the faculty senate for possible approval by the CSD. I assume
that if he is going to do that, that he will circulate any relevant
materials before the meeting. The faculty candidates will be
decided on first, however.
Thanks for your forbearance on this.
-Nils
∂13-Feb-89 1332 barwise@russell.Stanford.EDU SS GRad students
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Feb 89 13:32:13 PST
Received: from localhost by russell.Stanford.EDU (4.0/inc-1.0)
id AA29399; Mon, 13 Feb 89 13:33:12 PST
Message-Id: <8902132133.AA29399@russell.Stanford.EDU>
To: ssp-faculty@russell.Stanford.EDU
Subject: SS GRad students
Date: Mon, 13 Feb 89 13:32:30 PST
From: Jon Barwise <barwise@russell.Stanford.EDU>
I am using this mailing list as a catchall for faculty interested in
symbolic systems, and the questin of who the phil dept admits in the
new symbolic systems track in philosophy. I need to report to the
admissions committee on Thursday. So here is what I plan to say
unless some of you look at the files and give me contrary advise:
There are seven applicants, 4 strong, 2 ok, and one non-starter.
Here is my ranking of the top four, with comments:
1. Eric Jackson, AB from Harvbard in CS and Philosophy, GRE
percentiles 99/99/99. VERY strong letters and grades, wrote an
honor's thesis on Frege's puzzle, interested in AI and philosophy of
mind, currently working at a software company. Sounds brilliant. He
applied to cs this year before learning of the ss track. Says this is
his first choice.
2. Guven Guzeldere, a Turkish student, not getting an MS in CS and an
MA in philosophy at INdicate university. GRE percentiles: 52/97/97.
Persumably the score on verbal has to do with english being a second
language. Very good letters from people in cs and philosophy.
Interested in AI and phil of mind.
I think the first two are close. The next is still good, but not
quite as super.
3. Lawlor, Krista, BA in math from Univ of NH, current head of
academic computing at St Anslems college, GRE 98/79/88, interested in
philosophy of logic, math, and computation. Would probably make it
through and write a good dissertation.
4. Leong, M-K, Cog sci and c.s. degree from Toronto, from Singapore
lab, and does not need any money, will go back to lab. He is
interested in computational aspects of the relation between perception
and natural language. He applied to the c.s. dept last year, and was
turned down. He does not have that strong a philosophy background.
But his c.s. letters are strong. GRE 95/99/99. With him the question
is whether to recommend acceptance without aid. I hesitate because
of the lack of preparation in philosophy. If it were a straight ss
program, I would feel more comfortible.
Left to my own devices, I would recommend giving a fellowship or
RAship (if we have either) to Jackson and putting Gulzeldere and then
Lawlor on the waiting list. Though I think Jackson would accept, and
if he didn't, then I am almost positive G would, since I get a
computer message from him every few days. My inclination would be to
turn Leong down, for the reasons mentioned.
--------
There is also one regular applicant in philosophy who would be among
the top two here if she had applied for the SS track. That is, I
think I would have ranked her second. But she does not want to apply
for the tack, either because she wants to keep her options open, or
because she realizes she has a better chance in a bigger pool with
more fellowships. She is:
Teresa Robertson, top student in some years in phil from Univ of
Washington, not as much work in c.s. as the top two above, but
fantastic letters and grades. GRE 91/98/99. My bet is she will get
into the top 10 and probably get an offer. If not, I would consider
pushing her to our number 2. I suspect her work would be in some
aspect of ss, but she is not now as focued as either (1) or (2) above.
If you would like to look at the files, go to the phil office and
identify yourself to Marti Lacey, and ask for the ss files. Of if you
know anything about any of these candidates by some other route, let
me know. I would appreciate any comments I can get.
Thanks,
Jon
∂13-Feb-89 1404 lansky@ai.sri.com AI-RR SEMINAR REMINDER -- TUESDAY AT 2PM
Received: from Warbucks.AI.SRI.COM ([128.18.3.1]) by SAIL.Stanford.EDU with TCP; 13 Feb 89 14:04:45 PST
Received: from venice.ai.sri.com by Warbucks.AI.SRI.COM with INTERNET ;
Mon, 13 Feb 89 13:40:54 PST
Received: by venice.ai.sri.com (3.2/4.16)
id AA20534 for planlunch@ai.sri.com; Mon, 13 Feb 89 13:40:56 PST
Date: Mon 13 Feb 89 13:40:55-PST
From: LANSKY@Warbucks.AI.SRI.COM (Amy Lansky)
Subject: AI-RR SEMINAR REMINDER -- TUESDAY AT 2PM
To: planlunch@Warbucks.AI.SRI.COM
Message-Id: <603409255.0.LANSKY@VENICE.ARPA>
Mail-System-Version: <SUN-MM(229)+TOPSLIB(128)@VENICE.ARPA>
VISITORS: Please arrive 5 minutes early so that you can be escorted up
from the E-building receptionist's desk. Thanks!
-----------------------------------------------------------------------
A THREE-LEVEL THEORY OF REASONING
Wlodek Zadrozny (WLODZ@IBM.COM)
IBM T.J.Watson Research Center
2:00 PM, TUESDAY, February 14
SRI International, Building E, Room EJ228
In this talk we present a three-level theory of reasoning; we also
sketch some applications to semantics of natural language. In this
theory knowledge bases containing defaults are understood not as sets
of formulas (rules and facts) but as collections of partially ordered
theories. As a result of this shift of perspective we obtain a rather
natural logical system in which priorities in interpretation of
predicates are the source of nonmonotonicity in reasoning. In our
formalization, the usual, two-part logical structures, consisting of a
metalevel and an object level, are augmented by a third level -- a
referential level. The referential level is a partially ordered
collection of default theories -- it contains a more permanent part of
a knowledge base; current situations are described on the obect level;
the metalevel is a place for rules that can eliminate some of the
models permitted by the object level and the referential level. We
also prove basic results about derivability in this system. Finally,
commonsense conclusions of an object theory can be identified with
sentences true in a set of models specified by this three-level
semantics.
-------
∂13-Feb-89 2001 misha@polya.Stanford.EDU AFLB tomorrow at 11 am!
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Feb 89 20:01:31 PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA06884; Mon, 13 Feb 89 19:56:31 -0800
Date: Mon, 13 Feb 89 19:56:31 -0800
From: Michael Kharitonov <misha@polya.Stanford.EDU>
Message-Id: <8902140356.AA06884@polya.Stanford.EDU>
To: aflb-all@polya.Stanford.EDU
Subject: AFLB tomorrow at 11 am!
Sorry for the short notice - I just noticed that
my earlier posting bounced back.
Mauricio Karchmer will speak at AFLB tomorrow, Feb 14.
Please note UNUSUAL TIME: the talk will be at 11 am in room 352.
Communication Complexity & Circuit Complexity
Mauricio Karchmer
University of Toronto
Three approaches to the $NC↑1$ vs. $P$ question will be presented.
All three approaches are based on the equivalence between
circuit depth and some problems in communication complexity.
We are going to motivate each of the approaches and state intermediate
questions that may give ideas for the general problem.
----------------------------------------------------------------------
Zvi Galil from Columbia University will be speaking at AFLB next week.
∂13-Feb-89 2222 @Score.Stanford.EDU:jle@Orange.stanford.edu CS Colloquium/Forsythe Lecture
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Feb 89 22:22:32 PST
Received: from Orange.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 13 Feb 89 22:15:31-PST
Received: by Orange.stanford.edu (5.59/25-eef) id AA02720; Mon, 13 Feb 89 22:16:03 PDT
Date: Mon, 13 Feb 89 22:16:03 PDT
From: Jeffrey Eppinger <jle@Orange.stanford.edu>
Message-Id: <8902140616.AA02720@Orange.stanford.edu>
To: csd-list@score
Subject: CS Colloquium/Forsythe Lecture
Reminder: the next CS Colloquium will be (today) February 14th.
This colloquium is also the second of this year's Forsythe Lectures.
Computer Science Colloquium
Tuesday, February 14, 1989, 4:15pm
Jordan Hall (Building 420), Room 040
Stanford University
Perception via Active Exploration
Examples of Disassembly
Ruzena Bajcsy
Computer and Information Science Department
University of Pennsylvania
Philadelphia, PA 19104-6389
Abstract
It has been accepted by most psychologists (e.g., Gibson) that perception
is an active process, that is, an interaction of the perceptual system with
its environment. In this presentation we shall limit the perceptual system
to only two modalities: the Visual and the Haptic. The goal of our work is
to answer *what are the primitive actions and attributes* that are measurable
and or computable from Visual and Haptic modality that are necessary for
dissassembly of a scene or a two part-object. While a great deal of attention
has been paid to visual information processing both in psychological and
machine perception literature, haptic processing always took the second seat.
Haptic information processing is the identification of objects by touch (the
use of kinesthetic and tactile information). We shall develop a theory and
present two experiments to show an existential proof of our theory. Another
obvious observation is that vision is limited, especially in discerning two
separate objects when touching from the case of part-whole relationship of
one object. Take an example of a cup on a saucer. From vision alone one
cannot establish whether the saucer is glued to the cup or the cup is just
sitting on the saucer. The only way to disambiguate this situation is to
pick up the cup or shake it, in other words to perform some manipulation
operation.
The goal of this research is perception (apprehension) via exploration.
This means to us data driven perception which results in discerning solid
separable objects and describing them in terms of their structural and
geometric properties. Our aim is to explore complex scenes composed of more
than one object in arbitrary positions. Our basic hypothesis is that this
cannot be done by vision alone, that one needs some possibilities of
manipulation and the use of haptic information processing. Much of our
stimulation, especially in the area of haptic information processing, comes
from the studies and discussions of Klatzky and Lederman.
∂14-Feb-89 0309 hoffman@csli.Stanford.EDU The Symbolic Systems Forum, Feb. 17th
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Feb 89 03:09:28 PST
Received: by csli.Stanford.EDU (4.0/inc-1.0)
id AA16508; Tue, 14 Feb 89 02:59:54 PST
Date: Tue 14 Feb 89 02:59:53-PST
From: Reid Hoffman <HOFFMAN@CSLI.Stanford.EDU>
Subject: The Symbolic Systems Forum, Feb. 17th
To: ThisWeeksForum@csli.Stanford.EDU
Message-Id: <603457193.0.HOFFMAN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
The Symbolic Systems Forum
presents
Professor David Wellbery (German Studies)
on
Semiotics
However, the idea of this talk will be to explain why Symbolic Systems should
consider the Humanities as a part of its major. There has been much work on
symbols, symbolism, meaning, interpretation and much more in the Humanities
(principally Semiotics, Literary Theory, and Symbolic Anthropology), which
researchers and students in Symbolic Systems could use and might miss
otherwise. On the other hand, as in every case of collaboration, these
Humanities disciplines also stand to gain great benefit from ideas within
technical Symbolic Systems. In this vein, Professor Wellbery hopes to hold an
informal discussion in which he will present some ideas Semiotics and
attempt to justify collaboration through exploring the possibilities of
dialogue between the technical and humanities sides of Symbolic Systems.
Time: Friday 3:15, Feb 17th
Place: Building 60, room 62n.
The talk is open to the general public.
-------
∂14-Feb-89 0904 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Faculty Lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Feb 89 09:04:48 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 14 Feb 89 09:01:37-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA23762; Tue, 14 Feb 89 08:59:37 -0800
Date: Tue, 14 Feb 1989 8:59:30 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, bureaucrats@score
Cc: staff-rep@score
Subject: Faculty Lunch
Message-Id: <CMM.0.87.603478770.chandler@polya.stanford.edu>
Everything is set for another great discussion about the PhD program. The
room has been reserved (MJH-146), the time set (12:15), the caterer alerted
(you'll have to come to find out what the special of the day will
be)......all that's needed is for you to come on down and join in on today's
faculty lunch.
Will the bureaucrats please alert interested PhD students to join in?
∂14-Feb-89 0922 X3J13-mailer X3J13/ISO overlap
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 14 Feb 89 09:22:21 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00787g; Tue, 14 Feb 89 09:16:35 PST
Received: by challenger id AA02286g; Tue, 14 Feb 89 09:12:12 PST
Date: Tue, 14 Feb 89 09:12:12 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8902141712.AA02286@challenger>
To: x3j13@sail.stanford.edu
Subject: X3J13/ISO overlap
ISO will be meeting at the following times:
Thursday, 3/30 2:00 - 6:00
Friday, 3/31 9:00 - 5:00
Saturday, 4/1 9:00 - 1:00, if necessary (determined at Friday's meeting)
All meetings will be held at CONTEL.
---jan---
∂14-Feb-89 1012 aaai@sumex-aim.stanford.edu Next Council Meeting
Received: from sumex-aim.stanford.edu by SAIL.Stanford.EDU with TCP; 14 Feb 89 10:12:35 PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA04449; Tue, 14 Feb 89 10:04:39 PST
Date: Tue, 14 Feb 1989 10:04:38 PST
From: AAAI <aaai@sumex-aim.stanford.edu>
To: officers:;@sumex-aim.stanford.edu
Cc: aaai@sumex-aim.stanford.edu
Subject: Next Council Meeting
Message-Id: <CMM.0.88.603482678.aaai@sumex-aim.stanford.edu>
We've scheduled the next Council meeting for Thursday, March 30 in room
220 in Margaret Jacks Hall at Stanford University at 1:30 pm.
Please RSVP because we will be serving lunch at that time.
-Claudia
∂14-Feb-89 1226 X3J13-mailer Copying and Equality paper
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 14 Feb 89 12:25:55 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 14 Feb 89 15:18:15 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 14 Feb 89 15:20:39 EST
Date: Tue, 14 Feb 89 15:23 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Copying and Equality paper
To: x3j13@sail.stanford.edu
Message-Id: <19890214202339.8.BARMAR@OCCAM.THINK.COM>
Last month I distributed a draft of a paper on Copying and Equality at
the X3J13 meeting, hoping to get comments before I submit it to Lisp
Pointers. I got one verbal comment at the meeting, but I've received
nothing since. I'd like to work on it some more soon, so if you've got
any comments, please send them.
barmar
∂14-Feb-89 1235 SLOAN@Score.Stanford.EDU
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Feb 89 12:34:57 PST
Date: Tue 14 Feb 89 12:20:05-PST
From: Yvette Sloan <SLOAN@Score.Stanford.EDU>
To: csd@Score.Stanford.EDU, csd-list@Score.Stanford.EDU
Message-ID: <12470674334.24.SLOAN@Score.Stanford.EDU>
Departmental offices will close at 4:15 p.m. on Thursday, February 16, 1989
so that all may attend the Forum reception. Looking forward to seeing you
there.
***************************************************************************
**FORUM RECEPTION**
DATE: Thursday, February 16, 1989
TIME: 4:30-6:00 p.m.
PLACE: Faculty Club -- Red and Gold Lounges
-------
∂14-Feb-89 1240 @Score.Stanford.EDU:jle@Orange.stanford.edu Milk & Cookies
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Feb 89 12:40:01 PST
Received: from Orange.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 14 Feb 89 12:08:56-PST
Received: by Orange.stanford.edu (5.59/25-eef) id AA03129; Tue, 14 Feb 89 12:09:28 PDT
Date: Tue, 14 Feb 89 12:09:28 PDT
From: Jeffrey Eppinger <jle@Orange.stanford.edu>
Message-Id: <8902142009.AA03129@Orange.stanford.edu>
To: faculty@score, students@score
Subject: Milk & Cookies
The traditional milk and cookies that precede the CS Colloquium
will be consumed today at 3:45pm in the 3rd floor MJH lounge.
Jeff.
∂14-Feb-89 1318 snoeyink@polya.Stanford.EDU Bats Speakers and Abstracts
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Feb 89 13:18:32 PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA03809; Thu, 2 Feb 89 18:13:59 -0800
Date: Thu, 2 Feb 89 18:13:59 -0800
From: Jack Snoeyink <snoeyink@polya.Stanford.EDU>
Message-Id: <8902030213.AA03809@polya.Stanford.EDU>
To: aflb-local@polya.Stanford.EDU
Subject: Bats Speakers and Abstracts
Bats is Friday, Feb 10 at Berkeley.
The schedule is as follows:
10:10 Dorit Hochbaum (Berkeley): The Complexity of Integer Nonlinear
Optimization over Linear Polytopes
11:10 Peter Gacs (Boston University and IBM Almaden Research Center)
Self-correcting and self-organizing cellular arrays
12:10 Ashok Subramanian (Stanford) The Complexity of Circuit
Value and Network Stability
1:10 Seffi Naor (Stabford) Maximum Flow in Networks with Many
Sources and Sinks
---------------------------------------------------------------------
The complexity of integer nonlinear optimization over linear polytopes.
Dorit Hochbaum
University of California, Berkeley
We prove that concave separable objective optimization problems on
linear polytopes with polynomially bounded subdeterminants of the
constraint matrix can be solved in polynomial time. The integer
version of this problem is also solvable in polynomial time in the
same parameters, if the corresponding integer linear problem is
solvable in polynomial time (the algorithm will require a single
call to a routine that solves a linear integer problem on the same
polytope).
An important corollary is that nonlinear integer optimization with
concave (convex) separable objective function over a polytope
defined by a totally unimodular constraint matrix is a polynomial
problem. The running time of the algorithm is polynomial but not
strongly polyomial. It depends on the logarithm of the right hand
side vector in the constraint set. We provide a lower bound proof
to show that this problem cannot be solved in strongly polynomial
time. This is in contrast to the linear integer optimization over
a totally unimodular constraint matrix which is solvable in strongly
polynomial time (Tardos 86).
A special case of this problem is the integer nonlinear resource
allocation problem. We provide a algorithm for this problem which
is best possible for a certain class of such problems in that its
running time is equal to the lower bound on this problem's complexity.
For the quadratic separable case of this problem we describe a
strongly polynomial algorithm.
---------------------------------------------------------------------
Self-correcting and self-organizing cellular arrays
Peter Gacs
Boston University and IBM Almaden Research Center
A computer in the future may be just a large crystal of smart
molecules grown artificially. The components work according to
a probabilistic transition rule in continuous time. All
non-uniformity in structure is created by the machine itself,
responding to the demands of the computation to be carried out. One
can also arrive to the problems of reliability and self-organization
presented by the above requirement starting from an interest in the
origins of life. A soup of chemical ingredients, in a noisy
environment, started organizing itself and became able to carry out
larger and larger computations reliably. No hypotheses will be
stated on how this actually happened in nature, nor practical designs
offered of reliable computing molecules. But an example of a
transition rule will be given that provably satisfies all the
requirements. Its organizational principles are therefore worth
studying both for the design of future reliable computers and for
ideas on understanding biological evolution.
The new construction builds on earlier experience with reliable
cellular automata. Self-organization and continuous time are new, as
well as the primitive concepts allowing a modular design that is
easier to analyze.
---------------------------------------------------------------------------
The Complexity of Circuit Value and Network Stability
Ashok Subramanian
The Circuit Value problem asks for the output of an acyclic network of
boolean gates, given its inputs. The Network Stability problem asks if a
given network, possibly cyclic, of boolean gates has stable configurations.
(A stable configuration of a network is an assignment of truth values to
the edges of the network that respects all the gate equations.) We study
the complexity of these problems as a function of the kinds of gates
allowed in the network. In our model, gates may have many outputs, but no
fanout is allowed outside gates. This model permits the study of the effect
of fanout on the complexity of the above problems. The results: If the
gates do not `preserve adjacency' (in other words, if they can `make
copies' of their inputs), the problems are usually complete for a standard
complexity class like P or NP. But if the gates preserve adjacency, we get
new classes of problems, classes that lie between Logspace and P, but seem
incomparable to the parallel complexity class NC.
We identify an interesting subset of the adjacency-preserving gates, those
that lack `scatter'. Intuitively, a gate lacks scatter if it is never
possible for a small number of inputs to influence a larger number of
outputs. We give a linear time algorithm for the network stability problem
over scatter-free networks, and an O*(sqrt(n)) time algorithm for
scatter-free circuit value.
One of the most fundamental of the new classes is the class CC. Problems
complete for CC include Comparator Circuit Value, Lexicographically-first
Maximal Matching, and problems related to Stable Matching. Our approach to
Stable Matching is to regard it as a network stability problem. This
approach yields fresh insights and new algorithms.
(This work represents work done towards my doctoral dissertation, under the
direction of Ernst Mayr.)
---------------------------------------------------------------------------
Seffi Naor
Stanford University
The problem of maximum flow in planar graphs was always investigated
under the assumption that there is only one source and one sink.
We are going to consider the case where there are many sources and sinks in
a directed planar graph.
An algorithm for the case when the demands of the sources
and sinks are known will be presented which
can be implemented in parallel in $O(\log ↑2n)$ time
using $O(n↑{1.5})$ processors, and in sequential $O(n↑{1.5})$ time.
It uses a novel idea of redirecting
the flow back from the sinks to the sources and then reducing the problem to
that of computing a circulation.
If the demands are not known, we will show how to compute the max flow
in the special case when the sources and sinks are on
the same face.
This result has two applications:
it places the problem of computing a perfect matching in a planar
bipartite graph in NC; it improves a previous parallel
algorithm for the case of a single source, single sink in a planar
directed (and undirected) graph,
both in terms of time complexity and processor bound,
and in its simple presentation.
This is joint work with Gary Miller.
∂14-Feb-89 2115 LOGMTC-mailer "Categories for working logicians"
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Feb 89 21:15:27 PST
Received: by csli.Stanford.EDU (4.0/inc-1.0)
id AA15752; Tue, 14 Feb 89 21:13:32 PST
Date: Tue 14 Feb 89 21:13:31-PST
From: Sol Feferman <SF@CSLI.Stanford.EDU>
Subject: "Categories for working logicians"
To: logic@csli.Stanford.EDU
Message-Id: <603522811.0.SF@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
In Spring Quarter I plan to devote my Topics in Logic course to "Categories
for working logicians", mainly because they are part of the current culture
in logic and its applications that every logician should know something
about. I do not plan to hold a regular Logic Seminar, and this will free
up some time. There will probably be a related, but non-overlapping course
to be offered in the Computer Science Dept. by Eugenio Moggi, who will be
visiting from Edinburgh. We shall assume common background, namely
Chs. I-III in the book "Categories for the working mathematician" by
S. Mac Lane (or equivalent material). Tentative topics:
1. Review of basic category theory (categories, functors, limits, closure
conditions).
2. Topoi and sheaf models for intuitionistic theories.
3. Dilators (Girard's theory of ordinal functors) and PI-1-2 Logic.
4. Foundations of category theory.
In order to get through anything like the above amount of material, we
shall have to reduce detailed proofs to a minimum and concentrate on
concepts and examples and statements of results. Later in the quarter,
students may be asked to make seminar-type presentations.
The course is currently scheduled to meet TuTh 1:15-2:30, but another
possibility is MW 4:15-5:30. Please let me know if you're interested
and which time you prefer. Not limited to students, but meant for them.
If you have no background in category theory now's the time to start
picking it up.
S. Feferman
-------
∂15-Feb-89 0953 @Score.Stanford.EDU:chandler@polya.Stanford.EDU CSD Retreat
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Feb 89 09:53:34 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 15 Feb 89 09:50:21-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA15330; Wed, 15 Feb 89 09:51:00 -0800
Date: Wed, 15 Feb 1989 9:50:20 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score
Cc: chandler@polya.Stanford.EDU
Subject: CSD Retreat
Message-Id: <CMM.0.87.603568220.chandler@polya.stanford.edu>
The dates for the CSD faculty retreat have been set for May 5-6-7, 1989. The
retreat will again be held at Chaminade at Santa Cruz.
Nils is still thinking about the technical part of the program but would also
like to talk about strategic issues of importance to the Department. Please
send to me (chandler@polya) any suggestions you might have about the latter
topic.
The special rate Chaminade has offered us at this time will be $130.00 per
person, double occupancy and $195.00 per person, single occupancy. The
Department will pay for a double room. If you prefer a single please let me
know what account to charge the difference to.
I realize it is still quite early, but firm reservations must be made soon so
please let me know, as soon as possible, what accommodations you prefer.
∂15-Feb-89 1200 LOGMTC-mailer Thurs seminar
Received: from ra.stanford.edu by SAIL.Stanford.EDU with TCP; 15 Feb 89 12:00:53 PST
Received: by ra.stanford.edu (5.59/25-eef) id AA00159; Wed, 15 Feb 89 11:59:22 PDT
Date: Wed, 15 Feb 89 11:59:22 PDT
From: John Mitchell <jcm@ra.stanford.edu>
Message-Id: <8902151959.AA00159@ra.stanford.edu>
To: logmtc@sail
Subject: Thurs seminar
The Thurs lambda calculus and programming language theory
seminar will continue this week with an introduction to
logical relations. Handouts may be picked up in Rosemary
Napier's office (MJH 340) this week, or on Thursday.
∂15-Feb-89 1209 @Score.Stanford.EDU:tom@polya.Stanford.EDU Epoch Systems server/archive
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Feb 89 12:09:15 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 15 Feb 89 12:05:32-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA23918; Wed, 15 Feb 89 12:06:42 -0800
Date: Wed, 15 Feb 89 12:06:42 -0800
From: Tom Dienstbier <tom@polya.Stanford.EDU>
Message-Id: <8902152006.AA23918@polya.Stanford.EDU>
To: faculty@polya.Stanford.EDU, csd@polya.Stanford.EDU,
su-computers@polya.Stanford.EDU, admin@polya.Stanford.EDU
Subject: Epoch Systems server/archive
Reminder to come to the presentation on a new file/archive server
by Epoch Systems in room 252 building 460 at 1:30 to 3:00.
Tom Dienstbier
∂15-Feb-89 1451 TAJNAI@Score.Stanford.EDU Computer Forum Reception
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Feb 89 14:51:08 PST
Date: Wed 15 Feb 89 14:37:33-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Computer Forum Reception
To: csl-everyone@Sierra.Stanford.EDU, csd-list@Score.Stanford.EDU
Message-ID: <12470961503.15.TAJNAI@Score.Stanford.EDU>
Faculty, Staff, Students, and Friends
of the
Computer Science Department
and the
Computer Systems Laboratory
are invited to
attend the
Stanford Computer Forum Reception
which closes our
Twenty-first Annual Conference
Faculty Club -- Red and Gold Lounges
Thursday, February 16, 1989
4:30 - 6:00pm
-------
∂15-Feb-89 1541 barwise@russell.Stanford.EDU courses for next year
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Feb 89 15:40:57 PST
Received: from localhost by russell.Stanford.EDU (4.0/inc-1.0)
id AA14704; Wed, 15 Feb 89 15:42:02 PST
Message-Id: <8902152342.AA14704@russell.Stanford.EDU>
To: ssp-faculty@russell.Stanford.EDU
Subject: courses for next year
Date: Wed, 15 Feb 89 15:41:59 PST
From: Jon Barwise <barwise@russell.Stanford.EDU>
Be sure to keep SSP in mind as your department schedules classes
for next year. This year we ran into some pretty bad conflicts.
Helen is preparing our "wish list" for when courses would be given.
Thanks for your help.
∂15-Feb-89 1656 HEMENWAY@Score.Stanford.EDU The Last Batch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Feb 89 16:56:29 PST
Date: Wed 15 Feb 89 16:53:56-PST
From: Sharon Hemenway <HEMENWAY@Score.Stanford.EDU>
Subject: The Last Batch
To: phd-adm@Score.Stanford.EDU
Message-ID: <12470986329.12.HEMENWAY@Score.Stanford.EDU>
This is just a reminder (to those of you haven't already returned your
last batch) that even though we are not giving out another batch of
applications tomorrow, I still need the rated folders you have now
back as early as possible tomorrow (Thursday) morning. I can't begin
to prepare the necessary reports for our Monday meeting until I have
entered all of the ratings from the last batch so the earlier I have
all of the folders back, the better.
Anyway...you get the picture...thanks for your help.
See you all Monday at 3:00 in MJH 252 (please keep in mind that since
it is an official University holiday, the outside doors will be
locked).
Sharon
-------
∂16-Feb-89 0427 barwise@russell.Stanford.EDU grad courses and seminars
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Feb 89 04:26:57 PST
Received: from localhost by russell.Stanford.EDU (4.0/inc-1.0)
id AA17417; Thu, 16 Feb 89 04:28:12 PST
Message-Id: <8902161228.AA17417@russell.Stanford.EDU>
To: ssp-faculty@russell.Stanford.EDU
Subject: grad courses and seminars
Date: Thu, 16 Feb 89 04:28:11 PST
From: Jon Barwise <barwise@russell.Stanford.EDU>
To the consulting faculty:
This is the time when courses are being planned for next year.
I would like to encourage the ss consulting faculty to step forward
and volunteer to give a course or seminar at any level from
introductory for undergraduates, to the most advances, for
graduate students.
If we are going to have the graduate program, we really need some help
with graduate courses. As the list of propspective students shows,
the main interest in {AI,philosophy}. These are REALLY bright
students, and they could bring a lot to the field. But only if there
is faculty support for them. And given the field, this is not
something the regular members of the philosophy department can
provide. So before I recommend accepting any of them, I want to be
sure there is the support from the relavant faculty, including
consulting faculty.
You are all consulting faculty in SS, so courses can be given through
there. Just offer, and we will list the courses. Or you can also
do it through your home departments, and we will cross list. But
please don't be coy. We need your help. And I need to know more or
less immediately that there is support, and in the next two weeks what
courses or seminars you are willing to offer.
Thanks for your help.
Jon
∂16-Feb-89 0431 barwise@russell.Stanford.EDU Re: grad courses and seminars
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Feb 89 04:31:21 PST
Received: from localhost by russell.Stanford.EDU (4.0/inc-1.0)
id AA17447; Thu, 16 Feb 89 04:32:05 PST
Message-Id: <8902161232.AA17447@russell.Stanford.EDU>
Cc: ssp-faculty@russell.Stanford.EDU
Subject: Re: grad courses and seminars
In-Reply-To: Your message of Thu, 16 Feb 89 04:28:11 PST.
<8902161228.AA17417@russell.Stanford.EDU>
Address: CSLI, Stanford University, Stanford, CA 94305 (415) 723-0110
Date: Thu, 16 Feb 89 04:32:02 PST
From: Jon Barwise <barwise@russell.Stanford.EDU>
Sorry for all the typos in the previous message. It is too early in
the morning for typing. But I trust you get the idea.
Jon
∂16-Feb-89 0859 GOTELLI@Score.Stanford.EDU New Rates for Polya
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Feb 89 08:59:03 PST
Date: Thu 16 Feb 89 08:40:16-PST
From: Lynn Gotelli <GOTELLI@Score.Stanford.EDU>
Subject: New Rates for Polya
To: Faculty@Score.Stanford.EDU, CSD@Score.Stanford.EDU
Message-ID: <12471158606.9.GOTELLI@Score.Stanford.EDU>
Retroactive to 1/1/89 CF has approved new and lower rates for Polya.
CF has been able to adjust the rates for Polya because actual usage
has exceeded our original estimated usage figures. All other rates
remain the same. Following are new rates for Polya:
COMPUTER SCIENCE DEPARTMENT COMPUTER FACILITIES
SERVICE CENTER RATES
1/1/89
TIME WEEKDAY WEEKEND
--------- --------- ---------
"A" RATES = 100% 0000-0800 C C
"B" RATES = 66.67% * "A" RATE 0800-1300 A C
"C" RATES = 33.33% * "A" RATE 1300-1800 A B
1800-2400 B C
-------TIME OF DAY RATES---------
"A" RATES "B" RATES "C" RATES FIXED RATES
--------- --------- --------- -----------
Polya
Account charge Accts @ 5.00
Connect time hours @ 0.10 0.07 0.03
CPU time Minutes @ 1.17 0.78 0.39
Disk space Mbits/Mo @ 1.11
-------
∂16-Feb-89 0905 hyde@csli.Stanford.EDU csli calendar, Feb. 16, 4:16
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Feb 89 09:04:56 PST
Received: by csli.Stanford.EDU (4.0/inc-1.0)
id AA25218; Thu, 16 Feb 89 08:15:26 PST
Date: Thu, 16 Feb 89 08:15:26 PST
From: hyde@csli.Stanford.EDU (Dawn Hyde)
Message-Id: <8902161615.AA25218@csli.Stanford.EDU>
To: emma@csli.Stanford.EDU
Subject: csli calendar, Feb. 16, 4:16
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
16 February 1989 Stanford Vol. 4, No. 16
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR THIS THURSDAY, 16 February 1989
12 noon TINLunch
Cordura Hall Defeasible Reasoning and Nonmonotonic
Conference Room (and worse) Inference Relations:
A Little Philosophy; A Little AI; A Little Logic
David Israel
(israel@ai.sri.com)
Abstract below
2:15 p.m. CSLI Seminar
Cordura Hall Overview of the German Research Center for AI
Conference Room Gerhard Barth
German Research Center for AI
Abstract below
3:30 p.m. Tea
Ventura Hall
____________
THIS WEEK'S TINLUNCH
Defeasible Reasoning and Nonmonotonic
(and worse) Inference Relations:
A Little Philosophy; A Little AI; A Little Logic
David Israel
16 February
Starting about a decade ago, researchers in Artificial Intelligence
began to formalize certain oddly behaved, in particular nonmonotonic,
inference patterns. Some of these, e.g., Reiter's logic for default
reasoning, modeled features of actually existing computational
systems; others, such as circumscription, were presented as capturing
important features of actual, human common-sense reasoning. In both
kinds of case, the phenomenon under consideration has something to do
with what philosophers have called `defeasible reasoning.'
The latter will be very briefly characterized. We shall then move
on to recent attempts by logicians Dov Gabbay, on the one hand, and
David Makinson, on the other, to give abstract axiomatic accounts of a
variety of these nonmonotonic inference relations. These will be
described and some important results mentioned. A few questions will
be raised about what such inference relations have to do with
defeasible reasoning. `Many' fewer answers will be suggested.
____________
THIS WEEK'S SEMINAR
Overview of the German Research Center for AI
Gerhard Barth
German Research Center for AI
16 February
The German Research Center for AI was founded just recently. In this
talk, an overview of its structure, organization, and short-term
research program will be presented. One of the research projects that
has already been started is concerned with knowledge-based
presentation of information. Some specific issues of this project
will be discussed in the second half of the talk.
____________
LINGUISTICS DEPARTMENT COLLOQUIUM
A Typology of Possible Morphophonological Change
Bill J. Darden
University of Chicago
Friday, 17 February, 3:15
Cordura Hall Conference Room
Morphonological rules, being phonologically unmotivated, can be seen as
creating formal and semiotic problems. They have to be learned and
they create unmotivated allomorphy. They also may serve as auxiliary
signs themselves. Changes can generally be classified as those that
solve the problems or those that enhance the sign value of the
alternation. These changes indicate the close ties of
morpho-phonology to morphology. Other changes indicate close ties
with phonology. There are phonologically motivated adjustments in
morphonological rules, and morphologically motivated adjustments
in phonological rules (which may result in the elimination
of the rules). Ultimately, however, the phonologically motivated
changes can be interpreted as morphologically motivated, and the
morphological influence on phonological rules can be limited to the
morphological aspect (the input).
_____________
SYMBOLIC SYSTEMS FORUM
Semiotics
David Wellbery
German Studies
Friday, 17 February, 3:15
Room 60:61G
David Wellbery will explain why symbolic systems should consider the
humanities as a part of its major. There has been much work on
symbols, symbolism, meaning, interpretation, and much more in the
humanities (principally semiotics, literary theory, and symbolic
anthropology), which researchers and students in symbolic systems
could use and might miss otherwise. On the other hand, as in every
case of collaboration, these humanities disciplines also stand to gain
great benefit from ideas within technical symbolic systems. In this
vein, Professor Wellbery hopes to hold an informal discussion in which
he will present some ideas about semiotics and attempt to justify
collaboration.
___________
THE HISTORICAL LINGUISTICS INTEREST GROUP
The Diachronic Typology of Possessives
Dr. Vjacheslav V. Ivanov
Professor of History of Culture, Moscow University
Thursday, 23 February, 5:30
Ventura Hall Seminar Room
Refreshments will be served at 5:00.
____________
SYMBOLIC SYSTEMS FORUM
Turing's Oracle
Solomon Feferman
Department of Mathematics
Friday, 24 February, 3:15
Room 60:62N
____________
LINGUISTICS DEPARTMENT COLLOQUIUM
Cross-Linguistic Properties
of Anaphoric Systems
Peter Sells
Department of Linguistics
Friday, 24 February, 3:30
Cordura Hall Conference Room
____________
∂16-Feb-89 1302 @Score.Stanford.EDU:katiyar@polya.Stanford.EDU WINTER POTLUCK
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Feb 89 13:02:22 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 16 Feb 89 12:50:11-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA23418; Thu, 16 Feb 89 12:51:38 -0800
Date: Thu, 16 Feb 1989 12:51:35 PST
Sender: "Dinesh H. Katiyar" <katiyar@polya.stanford.edu>
From: Social Committee <katiyar@polya.stanford.edu>
To: faculty@score, research-associates@score, secretaries@score,
students@score
Subject: WINTER POTLUCK
Message-Id: <CMM.0.87.603665495.katiyar@polya.stanford.edu>
*************************************************************************
********************* 1989 WINTER QUARTER POTLUCK **********************
*************************************************************************
It's potluck time again !!
This time it's at Prof. Vaugh Pratt's place at 12 noon on the 26th of
February. Directions to his house are given below.
All faculty, staff, students (Ph.D.,Masters and Undergrads) and their
guests are welcome.
If you wish to come, edit the potluck database by typing " ~katiyar/food "
on polya and follow the directions.
Those of you who don't have accounts on polya can send mail to one
of the members of the social committee.
Please respond as soon as possible.
The map for Vaughn's house:
_________________________________________________| |__________________________
__________________________________Foothill______Light______Expressway_________
Vaughan and Margot Pratt |P|
Street address: 2215 Gerth Lane /.a|.....one way - no entry to
Los Altos Hills //|g| Old Page Mill Road
Phone: 494-2545 // |e|
<PO address: 2215 Old Page Mill Rd. // | |
Palo Alto, CA 94304> Old || |M|
DIRECTIONS Page|| |i|
Take Page Mill to near 280 Mill|| |l|
Follow sign to Old Page Mill Road Road|| |l|
Gerth Lane has row of mailboxes............|| Light_________________________
:|| |E --------------------------
Cross bridge........................... :|| |x| Deer Creek Road
2215 is second on left....... : :|| |p|
: : :|| |w|
Gerth Lane : : :|| |y| only entry to
=================:=========#===:= === .!.....Old Page Mill Road
2215 2209 M \\ | | and Gerth Lane
<not to scale> \\| |
\ |
_________________________________________________| |_________________________
_<--SF______________________Route 280____________ _____________________SJ-->
*************************************************************************
Student Social Committee
------------------------
jennifer anderson jaikumar ramanathan dinesh katiyar
anderson@polya jaikumar@polya katiyar@polya
*************************************************************************
∂16-Feb-89 1657 @Score.Stanford.EDU:goldberg@Jinn.stanford.edu Needed: Industrial Lecturers
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Feb 89 16:57:31 PST
Received: from Jinn.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 16 Feb 89 16:46:57-PST
Received: by Jinn.stanford.edu (4.0/25-eef) id AA01040; Thu, 16 Feb 89 16:47:55 PST
Date: Thu, 16 Feb 89 16:47:55 PST
From: Andrew Goldberg <goldberg@Jinn.stanford.edu>
Message-Id: <8902170047.AA01040@Jinn.stanford.edu>
To: faculty@score
Subject: Needed: Industrial Lecturers
We are still in the process of looking for Industrial Lecturers for
the next year. The best candidates are probably the ones who are known
to the CS faculty. If you know someone who will make a great Industrial
Lecturer and who may be willing to do the job, please let me know!
--Andy
∂16-Feb-89 1808 tah@polya.Stanford.EDU MTC Seminar
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Feb 89 18:08:06 PST
Received: from LOCALHOST by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA13639; Thu, 16 Feb 89 18:06:47 -0800
Message-Id: <8902170206.AA13639@polya.Stanford.EDU>
To: lop@polya.Stanford.EDU
Subject: MTC Seminar
Date: Thu, 16 Feb 89 18:06:45 -0800
From: Tom Henzinger <tah@polya.Stanford.EDU>
Friday, Feb. 17, noon (MJH 301):
I'll continue with Abramsky's POPL tutorial on process equivalences,
where we left off two weeks ago.
-- Tom.
∂17-Feb-89 0003 @Score.Stanford.EDU:marty@cis.Stanford.EDU WINTER POTLUCK
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Feb 89 00:03:33 PST
Received: from cis.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 16 Feb 89 23:58:32-PST
Received: by cis.Stanford.EDU (5.59/inc-1.0)
id AA08840; Thu, 16 Feb 89 23:57:21 PDT
Date: Thu, 16 Feb 89 23:57:21 PDT
From: marty@cis.Stanford.EDU (Marty Tenenbaum)
Message-Id: <8902170757.AA08840@cis.Stanford.EDU>
To: katiyar@polya.stanford.edu
Cc: faculty@score.stanford.edu, research-associates@score.stanford.edu,
secretaries@score.stanford.edu, students@score.stanford.edu
In-Reply-To: Social Committee's message of Thu, 16 Feb 1989 12:51:35 PST <CMM.0.87.603665495.katiyar@polya.stanford.edu>
Subject: WINTER POTLUCK
I will try to come with my wife. What can I bring (that wont be missed if
circumstances prevent me from coming - 25% possibility).
JMT.
∂17-Feb-89 0014 @Score.Stanford.EDU:marty@cis.Stanford.EDU Needed: Industrial Lecturers
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Feb 89 00:14:43 PST
Received: from cis.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 17 Feb 89 00:06:03-PST
Received: by cis.Stanford.EDU (5.59/inc-1.0)
id AA08856; Fri, 17 Feb 89 00:04:55 PDT
Date: Fri, 17 Feb 89 00:04:55 PDT
From: marty@cis.Stanford.EDU (Marty Tenenbaum)
Message-Id: <8902170804.AA08856@cis.Stanford.EDU>
To: goldberg@Jinn.stanford.edu
Cc: faculty@score.stanford.edu
In-Reply-To: Andrew Goldberg's message of Thu, 16 Feb 89 16:47:55 PST <8902170047.AA01040@Jinn.stanford.edu>
Subject: Needed: Industrial Lecturers
Mark Stefik of Xerox Parc is writing a new book on AI, in which the
various modeling and representation techniques are presented as
engineering tools. He is a very effective lecturer, and may be
interested in trying a class based on the book.
JMT.
∂17-Feb-89 0019 @Score.Stanford.EDU:marty@cis.Stanford.EDU CSD Retreat
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Feb 89 00:19:33 PST
Received: from cis.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 17 Feb 89 00:15:22-PST
Received: by cis.Stanford.EDU (5.59/inc-1.0)
id AA08887; Fri, 17 Feb 89 00:14:11 PDT
Date: Fri, 17 Feb 89 00:14:11 PDT
From: marty@cis.Stanford.EDU (Marty Tenenbaum)
Message-Id: <8902170814.AA08887@cis.Stanford.EDU>
To: chandler@polya.stanford.edu
Cc: faculty@score.stanford.edu, chandler@polya.Stanford.EDU
In-Reply-To: "Joyce R. Chandler"'s message of Wed, 15 Feb 1989 9:50:20 PST <CMM.0.87.603568220.chandler@polya.stanford.edu>
Subject: CSD Retreat
Joyce,
I would like to attend the retreat and stay in a single. Unfortunately,
I do not have any source of discretionary funds. Can the department
pick up my tab?
Thanks,
JMT.
∂17-Feb-89 0842 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu $50K
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Feb 89 08:42:32 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 17 Feb 89 08:39:11-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA05940; Fri, 17 Feb 89 08:38:48 PDT
Date: Fri, 17 Feb 89 08:38:48 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8902171638.AA05940@Tenaya.stanford.edu>
To: faculty@score
Subject: $50K
We have the opportunity of proposing for a $50K ATT grant. The
chances are very good that the proposal will be accepted. The grant
is to be used for a) education, b) beginning a new program, and/or c)
equipment for a lab BUT it cannot be used for things that NSF, say,
would ordinarily pay for such as faculty salaries or student support.
I promised Al Aho that I would send him an on-line proposal before the
first of March. The proposal should have a paragraph or two
describing what will be done with the funds and an expected budget.
Please send any ideas you might have to me, and I and the spokespeople
will decide on Feb. 27 which proposal to forward to Al. Thanks, -Nils
∂17-Feb-89 0909 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Next Tuesday's Faculty Lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Feb 89 09:09:53 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 17 Feb 89 09:06:48-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA06649; Fri, 17 Feb 89 09:08:03 -0800
Date: Fri, 17 Feb 1989 9:07:57 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, bureaucrats@score, staff-rep@score
Subject: Next Tuesday's Faculty Lunch
Message-Id: <CMM.0.87.603738477.chandler@polya.stanford.edu>
The topic to be discussed at next Tuesday's faculty lunch (12:15 in MJH-146)
will be "staff concerns". Mark your calendars!
∂17-Feb-89 0931 LOGMTC-mailer Logic Seminar
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Feb 89 09:31:30 PST
Received: by csli.Stanford.EDU (4.0/inc-1.0)
id AA09155; Fri, 17 Feb 89 09:29:37 PST
Date: Fri 17 Feb 89 09:29:36-PST
From: Sol Feferman <SF@CSLI.Stanford.EDU>
Subject: Logic Seminar
To: Logic@csli.Stanford.EDU
Message-Id: <603739776.0.SF@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
Seminar in Logic
Speaker: Prof. I. Katznelson, Stanford Mathematics Dept
Title: "Semigroups, idempotents, and Ramsey theory" (second of two lectures)
Time: Tues, Feb. 21, 4:15-5:30
Place: Room 381-T, Math Corner, Stanford
S. Feferman
-------
∂17-Feb-89 1139 @Score.Stanford.EDU:RWF@SAIL.Stanford.EDU Comprehensive Structure; Long-term Committees
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Feb 89 11:39:25 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 17 Feb 89 11:35:49-PST
Message-ID: <Y1Zt7@SAIL.Stanford.EDU>
Date: 17 Feb 89 1137 PST
From: Robert W Floyd <RWF@SAIL.Stanford.EDU>
Subject: Comprehensive Structure; Long-term Committees
To: faculty@Score.Stanford.EDU, phd-program@SAIL.Stanford.EDU
My opinion on the comprehensive exam, repeated from lunch of February 14.
Our historical experience with the comp over perhaps fifteen years has
until recently been tranquil; therefore, I think our current
dissatisfactions can not be inherent in having a requirement for passing a
breadth exam in two years. On the other hand, the exam does not get much
use as a final filter, in that almost everyone eventually passes it, so we
might consider extending the deadline to 2.5 or 3 years, to counterbalance
proposed early research requirements.
The comp embodies the material of a good many courses. The theory exam
covers much of the material of 160, 154 or 254, 257, 260, and more. Only
very well prepared entrants can hope to pass the comp after one quarter of
study; historically, no more than our top (perhaps) 20% have done so.
Students should not be led to feel they have failed if they do not pass
the first time. In fact, a student does not fail the exam until the end
of the second year. A non-pass is not a failure. A reasonable goal is to
pass one section each half year.
It is difficult to be on the comp committee, because we come onto it rusty
by several years, and find a new syllabus and regulations awaiting us.
The comp committee, like several other major committees, should be a
continuing body with staggered three-year terms of appointment (like the
major university committees). This permits the members, also, to maintain
collections of unused problem ideas, and to calibrate problems by
experience. One virgin per wedding night is plenty.
The current format of the comp sections, each broken into five named parts
with a tacit assumption of several problems per part, leads to a three
hour exam of a dozen or more problems, at best allowing fifteen minutes
per problem. This can not encourage students to reveal the depth of their
understanding. It also unduly contrains the committee to cover all the
bases rather than ask the best available questions. I would rather
present eight nontrivial questions, with the grade based on the student's
five best answers, to discourage wasting time trying for partial credits.
Uniform coverage of subdisciplines should not be expected.
I think we should prune subject matter. Areas subject to rapid
technological change especially should be prayerfully left to the
student's self-education in later life. Networks might go away, operating
systems and compilers could be covered only at the level of a good
software engineering survey text. The ruling question: is the half-life
of this technology greater than the median time to Ph.D.?
I return to a proposal briefly mentioned, namely long-term committee
appointments. Having been a long-term member of the MS committee, I have
appreciated reading MS admissions folders in the light of a set of
standards set by experience; it cuts the hard decisions in half, at least.
Some committees, such as curriculum, are subject to excessive thrashing
when staffed in a short-term way. On some committees, ex officio members
seem to have a disproportionate influence because of their longer tenure.
Couldn't we each be on one major committee for a (renewable?) three year
term? The committees I have in mind are Ph.D., MS, Undergrad, Curriculum,
Forum, and an executive council (i.e., the area spokesmen, with much
authority delegated to them).
∂17-Feb-89 1202 @Score.Stanford.EDU:goldberg@Jinn.stanford.edu Industrial Lecturers
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Feb 89 12:02:35 PST
Received: from Jinn.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 17 Feb 89 11:59:08-PST
Received: by Jinn.stanford.edu (4.0/25-eef) id AA01590; Fri, 17 Feb 89 12:00:07 PST
Date: Fri, 17 Feb 89 12:00:07 PST
From: Andrew Goldberg <goldberg@Jinn.stanford.edu>
Message-Id: <8902172000.AA01590@Jinn.stanford.edu>
To: faculty@score
Subject: Industrial Lecturers
Several faculty members suggested Mark Stefik, who is finishing a new
book on AI, as an excellent candidate. Unless someone tells me a reason
not to, I will try to convince Mark Stefik to teach a course next year.
--Andy
∂18-Feb-89 1439 @Score.Stanford.EDU:gio@sumex-aim.stanford.edu Re: Comprehensive Structure; Long-term Committees
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Feb 89 14:39:54 PST
Received: from sumex-aim.stanford.edu by SCORE.STANFORD.EDU with TCP; Sat 18 Feb 89 14:35:37-PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA22484; Sat, 18 Feb 89 14:36:57 PST
Date: Sat, 18 Feb 1989 14:36:56 PST
From: Gio Wiederhold <gio@sumex-aim.stanford.edu>
To: Robert W Floyd <RWF@sail.stanford.edu>
Cc: faculty@score.stanford.edu, phd-program@sail.stanford.edu
Subject: Re: Comprehensive Structure; Long-term Committees
In-Reply-To: Your message of 17 Feb 89 1137 PST
Message-Id: <CMM.0.88.603844616.gio@sumex-aim.stanford.edu>
1. On Committees: three year appointments, with a rolling chair, seem very
desirable.
2. To remove the double whammy of exams I propose a more radical change:
Do away with the Qual exams.
Why?
a. We need the Comps to satisfy the Universities rules for promotion
to candidacy.
b. Research students need breadth too, here and later.
c. We can use the topic area Comp results for assessing student preparation
d. Research progress with an advisor is the relevant criterium for
accepting a thesis student.
e. We save the second exam go around which must be continuously updated
to keep pace with the pace and specialization of CS.
Now passing the quals seems to give a guarantee to the student of being able
to do a thesis, but not neccessarily an advisor.
Gio
∂18-Feb-89 2234 @Score.Stanford.EDU:jcm@ra.stanford.edu Re: Comprehensive Structure; Long-term Committees
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Feb 89 22:34:51 PST
Received: from ra.stanford.edu by SCORE.STANFORD.EDU with TCP; Sat 18 Feb 89 22:30:34-PST
Received: by ra.stanford.edu (5.59/25-eef) id AA00944; Sat, 18 Feb 89 22:31:17 PDT
Date: Sat, 18 Feb 89 22:31:17 PDT
From: John Mitchell <jcm@ra.stanford.edu>
Message-Id: <8902190631.AA00944@ra.stanford.edu>
To: gio@sumex-aim.stanford.edu
Subject: Re: Comprehensive Structure; Long-term Committees
Cc: faculty@score
I think the Quals are useful.
∂19-Feb-89 1446 LOGMTC-mailer The Symbolic Systems Forum, Feb. 24th
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Feb 89 14:45:51 PST
Received: by csli.Stanford.EDU (4.0/inc-1.0)
id AA01100; Sun, 19 Feb 89 14:39:44 PST
Date: Sun 19 Feb 89 14:39:41-PST
From: Reid Hoffman <HOFFMAN@CSLI.Stanford.EDU>
Subject: The Symbolic Systems Forum, Feb. 24th
To: SymbolicSystemsForum@csli.Stanford.EDU
Message-Id: <603931182.0.HOFFMAN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
This week, The Symbolic Systems Forum presents
Professor Solomon Feferman,
Chairman Mathematics
on
Turing's "Oracle"
-----------------
This is the curious tale of a powerful and Protean idea. In the beginning
there was Alan Turing's theory of mechanical computability. Then Turing
introduced his idea of computability by means of an "oracle", but he never
did anything with it. Next, Emil Post took it up as the basis for his
theory of degrees of unsolvability. Then came generalized recursion
theory and even more generalized degrees of unsolvability. All of which
has nothing to do with actual computability, right? Wrong, in my view.
Date: Feb 24th
Time: 3:15
Place: building 60, room 60-61g
The talk is open to the general public and refreshments will be served.
-------
∂20-Feb-89 0129 X3J13-mailer Issue: SUBSETTING-POSITION
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 20 Feb 89 01:28:58 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA06837; Mon, 20 Feb 89 01:27:08 PST
Message-Id: <8902200927.AA06837@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 20 Feb 89 04:24
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: SUBSETTING-POSITION
Issue: SUBSETTING-POSITION
References: X3J13 committee and sub-committee meetings
Category: Policy
Edit history: 12-DEC-88, Version 1 by Chapman
9-JAN-89, Version 2 by Chapman
10-JAN-89, Version 3 by Chapman
20-FEB-89, Version 4 by Chapman
Problem Description:
Should the CL standard be partitioned such that an implementation
could chose a subset of all the CL facilities to implement and
still be a conforming implementation?
What subsets should be specified in the draft standard we submit to
ANSI?
What position should we take if someone should propose a subset?
Subsets might omit syntax, functions, admissable values or arguments
to functions, or data types. For example, a subset might disallow SPECIAL
declarations (a syntactic subset), might omit the COS, SIN, ATAN functions,
might disallow the :TEST keyword to MAKE-HASH-TABLE, might restrict TAILP
to work on proper lists, or might omit complex numbers. Each of these is a
"subset" in the sense that a subset of correct programs for the "full"
language would be correct for the "subset" language.
Subsets can have various levels of "determinability" for programs. The
issue is: how easy is it to tell whether a program written in the "full"
language would run in a "subset" implementation? Except for the
(non-trivial) issue of macro expansions, some subsets are "lexically"
determinable, e.g., if a function is omitted, you can tell if the program
uses it by scanning the program. Some subsets are "dynamically"
determinable, e.g, a subset might signal an error if the :TEST argument to
MAKE-HASH-TABLE is EQUALP. Some subsets are neither lexically nor
dynamically determinable, e.g., if the subset implements dynamic extent for
rest lists, it may be impossible to tell even with run-type checks whether
the a program written in the "full" language would conform.
Some "subsets" might be merely restrictive interpretations, e.g., a
"run-time" implementation that made ED, TRACE, UNTRACE into no-ops and made
BREAK halt the program execution rather than "enter the debugger"; since we
cannot define what "enter the debugger" means, we might want to define
explicitly this subset as a reasonable one for embedded systems.
Proposal (SUBSETTING-POSITION:NONE)
The draft standard we submit to ANSI contains *no* subsets.
In the section on "subsetting" it should be mentioned
that Lisp is a "small" language with a "big" library.
We are not opposed in principle to one or more subset definitions.
Rationale:
We have no well-defined proposals for subset definitions, and didn't have
the time or energy to pursue their definition, or confidence that we could
reach convergence on a reasonable definition.
There are several properties that a subset definition must have to be
considered: it must be well defined in terms of conformance of code, programs,
and implementations; all valid programs in the subset must be valid programs in
the full language; the subset definition should address how it can be
determined if a program in the full language is valid in the subset.
Current Practice:
Pascal has two levels of conforming implementations -- level 1 contains
level 0 and conformant arrays. This was a compromise necessary to achieve
international agreement. The 1981 PL/I was subsetted and the
results were a range of implementations between the
subset and the full language; nobody wanted to use the subset so vendors
were forced to implement the full language eventually anyway.
Cobol had multiple levels of subsets. However,
the only two levels that were important were the minimum
subset and the full language. The middle levels were
seldom used other than transient points to the full language.
Fortran was subsetted. It was felt that subsetting encouraged
vendors to implement Fortran and therefore proliferate its usage,
but users were quite annoyed that one Fortran was considerably
different from another.
The new Fortran language standards committee is
banning subsetting.
At one point, there was an ANSI standard for "Minimal Basic". It was
too minimal. Later work on ANSI Basic involved a rather different-looking
language and a number of optional extensions for such things as real-time process control.
SPARC feels that subsets aren't good for facilitating interchange, but serve the
purpose of allowing timely implementation of the standard.
Adoption Cost:
None.
Benefits:
This policy will provide a basis for making decisions in X3J13.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
Jeff Dalton says:
"I'd be happier if it were fairly easy for someone reading the standard
to determine which part was the "library" and which the core language.
For example, where do we find FUNCALL and APPLY?
The draft C standard has an explicit division. Section 3 is
"Language" and section 4 is "Library". It may not be necessary
to go that far for Common Lisp."
GLS says: "I am in agreement with SUBSETTING-POSITION:NONE."
Loosemore says: "... even if the standard doesn't define
any subsets, that is not going to prevent subsets from happening, and
perhaps the standard ought to define some terminology to describe such
implementations (even if it's only to say that they can't call
themselves Common Lisps at all)."
RPG says: "One point worth making might be that a conforming program that is
delivered may not also be a conforming implementation."
Paraphrased:
A conforming implementation does not have to be present in order to deliver
a conforming program.
One could produce a linkable version of an application that would
include almost no part of the Lisp environment.
Therefore, subsets are not mandated for this case.
∂20-Feb-89 1255 X3J13-mailer Re: Issue: SUBSETTING-POSITION
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 20 Feb 89 12:55:32 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA02399; Mon, 20 Feb 89 15:53:31 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA01512; Mon, 20 Feb 89 15:51:32 EST
Message-Id: <8902202051.AA01512@mist.>
To: "chapman%aitg.DEC@decwrl.dec.com"@multimax.encore.com
Cc: x3j13@sail.stanford.edu, "skona%csilvax@hub.ucsb.edu"@multimax.encore.com
Subject: Re: Issue: SUBSETTING-POSITION
In-Reply-To: Your message of 20 Feb 89 04:24:00 +0000.
Date: Mon, 20 Feb 89 15:51:29 EST
From: Dan L. Pierson <pierson@mist.encore.com>
I support SUBSETTING-POSITION:NONE in general (though I would still
like to see LOOP be optional :-) ).
However, this brushes on another issue: what to do about well
considered proposals which we generally approve of but don't want to
put in the standard at this time. Chapter 3 of CLOS is possibly the
least controversial member of this class. The OSS/Iterator proposal
and STREAM-INFO are other potential members.
I would very much like to see the standard include an official
appendix containing such features. The wrapper wording for the
appendix would state that these are not part of this Common Lisp
standard but will be considered for future versions of the standard
(note "will be considered", not "will be included"). Implementations
are in no way required to support these features, but if they do, they
should conform to these descriptions as much as possible to avoid
gratuitous incompatibilities. However, we recognize that, since these
features are new and somewhat experimental, it may be unreasonable for
an implementation to precisely conform to the any given description in
the appendix.
While the success of such an appendix will rely a great deal on the
good will of implementors, I believe that it will succeed to a large
extent and that it will make the work of the next standards committee
and the life of Common Lisp users easier.
∂20-Feb-89 1406 X3J13-mailer Issue: CONFORMANCE-POSITION
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 20 Feb 89 14:06:12 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA14009; Mon, 20 Feb 89 14:04:18 PST
Message-Id: <8902202204.AA14009@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 20 Feb 89 16:02
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: CONFORMANCE-POSITION
Issue: CONFORMANCE-POSITION
References: Chapter 1, Section 1.5, Working draft of standard
Category: Clarification
Related Issues: EXTENSIONS-POSITION, LISP-SYMBOL-REDEFINITION, PACKAGE-CLUTTER
Edit history: 12-DEC-88, Version 1 by Chapman
20-DEC-88, Version 2 by Chapman
9-JAN-89, Version 3 by Chapman
10-JAN-89, Version 4 by Chapman
6-FEB-89, Version 5 by Chapman
20-FEB-89, Version 6 by Chapman
Problem Description:
Two ways of defining conformance are in terms of a conforming program
and in terms of a conforming implementation. How should our standard
define conformance? What is the relationship between conformance and
portability?
Proposal (CONFORMANCE-POSITION:IMPLEMENTATION-AND-PROGRAM)
The standard presents the syntax and semantics to be implemented by
a conforming implementation.
The basic test for conformance will be that code written to the letter
of the standard will run in all "conforming" implementations.
The basic rules are as follows:
. Conforming code uses only the syntax specified in the standard.
. Conforming code is written into a program
in only the sequence specified in the standard.
. Conforming code is written using only the functions, macros,
special forms, variables, constants specified in the standard.
. Conforming implementations provide the functions, macros, special
forms, variables, constants, and arrange that they behave in ways
that conform to the specifications of them in the standard.
The definitions of all other functions, macros, or symbols must accompany
the program. Extensions to syntax are not allowed in conforming programs.
. Conformance will not be machine-checkable.
. Conforming programs will only be defined in terms of their structure.
It's possible for a conformal code to
run in all conformal implementations, but to have allowable
implementation-dependent behavior which could make it non-portable.
Insofar as we allow options in the standard this will be true.
Portable code is required to produce equivalent results and
observable side effects in all conforming implementations.
Rationale:
The standard must contain information about conformance. Only including
requirements which would be placed on implementations, however, leaves
the possiblity open that something would be overlooked, and so
implementations may well conform without processing correctly
conforming programs.
Current Practice:
CLtL generally describes things in terms of what correct code can
expect, but the document itself levies the requirement on an implementation
to support all the described functionality.
dpANS C also defined conformance in terms of programs.
It has further defined both "conforming" and "strictly conforming" programs.
Pascal defines conformance in terms of both, PL/I defines conformance in
terms of conforming programs only.
Fortran and Ada say that a conforming implementation correctly processes
conforming programs. Ada goes on to say other specific things about
a conforming implementation, Fortran does not at this time but probably
will in its next standard. The ISO conformance guidelines, and the
draft of the SPARC proposal discuss both programs and implementations.
Adoption Cost:
None.
Benefits:
This definition will give readers and validators a basis on which to read
the standard.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
∂20-Feb-89 1452 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu SIGACT Newletter
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Feb 89 14:51:54 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA05920; Mon, 20 Feb 89 14:50:47 -0800
Message-Id: <8902202250.AA05920@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Mon, 20 Feb 89 14:50:03 PST
Received: by BYUADMIN (Mailer R2.01A) id 6234; Mon, 20 Feb 89 15:48:31 MST
Date: Mon, 20 Feb 89 16:35:22 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Samir Khuller <khuller@CU-ARPA.CS.CORNELL.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Samir Khuller <khuller@CU-ARPA.CS.CORNELL.EDU>
Subject: SIGACT Newletter
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Announcement: Mike Langston has suggested that we start an "Open Problems"
column in the SIGACT newsletter. I will be compiling problems which people
may have to throw out to the general CS theory community. As J.O'Rourke is
already handling problems in Computational Geometry for his column -
submissions in that area should be sent directly to him.
The problems will (I think) vary in difficulty from some involving weeks
of work to years of work. The idea is to be able to also provide interesting
and challenging problems to graduate students to work on which may even be
significant enough to constitute thesis material.
People are welcome to send their problems to me for compilation and I would
request you to try and keep the statements of the problems to a reasonable
length. If you know of any work that has been done on the problem it would
be useful to provide appropriate references for the convenience of the
readers.
Problems may be submitted electronically or by physical mail to me. The
column will perhaps start functioning regularly this summer.
Samir
khuller@svax.cs.cornell.edu
Samir Khuller
Upson Hall
Dept. of Computer Science
Cornell University
Ithaca, NY 14853
USA
∂20-Feb-89 1747 misha@polya.Stanford.EDU Next AFLB
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Feb 89 17:47:17 PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA13719; Mon, 20 Feb 89 17:45:07 -0800
Date: Mon, 20 Feb 89 17:45:07 -0800
From: Michael Kharitonov <misha@polya.Stanford.EDU>
Message-Id: <8902210145.AA13719@polya.Stanford.EDU>
To: aflb-all@polya.Stanford.EDU
Subject: Next AFLB
The next AFLB will be on Thursday, February 23, at 12:30 in room 352.
The talk will be:
The subset-sum problem and analytic number theory -- an interplay
Zvi Galil
Department of Computer science
Columbia University and
Tel-Aviv University
One way of attacking NP-complete problems is to identify input
domains for which it is possible to design polynomial time
(or pseudo polynomial time) algorithms. For example, consider
the subset-sum problem. If the m summands are bounded by l,
one can solve the problem in time O(l m↑2) by dynamic programming.
G. Freiman initiated an entirely different approach for solving the
subset-sum problem. Using analytic number theory,
he and others proved theorems characterizing
the set of subset sums as a collection of arithmetic progressions
with the same difference. These theorems were used to design
algorithms for the subset-sum problem that improved the ones
using dynamic programming in case of dense enough inputs.
(A problem is dense if m is large enough as a function of l.)
More recently, a family of better algorithms was designed. They do not use
any analytic number theory, only elementary number theoretic
arguments. The fastest algorithms in the family run in time O(m),
and the slowest in time O(l log l). Moreover
the algorithms yield a characterization of the set of subset sums,
improving the theorems mentioned above.
The talk will discuss the approach, its potential
and its limitations.
Joint results with M. Chaimovich, G. Freiman and O. Margalit
of Tel-Aviv University.
∂21-Feb-89 0638 X3J13-mailer Updated version of standard available
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 21 Feb 89 06:38:41 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA03842; Tue, 21 Feb 89 06:36:49 PST
Message-Id: <8902211436.AA03842@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 21 Feb 89 09:31
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Updated version of standard available
I have put the latest version of the standard on hudson.dec.com
(ftp_user merrychristmas) for your access. Below are informational
comments and directions for building the standard.
Please let me know if you need help.
kathy chapman
How to build the Common Lisp working draft standard
Following are the files you'll need to build the standard and
the method for building the standard.
To build from scratch
1. You'll need to have AM fonts. If you only have CM fonts,
you'll have to wait a month or so until I can get my files
converted to CM fonts.
2. Copy all the files from hudson.dec.com, ftpuser, to your
directory where you plan to do the build. To decrease the
length of time it takes to copy, you don't need any files
with the .dvi or the .ln3 extension. It will be
approximately 9000 blocks.
3. The top level files you'll provide to your TEX processor
are named chapter1.tex, chapter2.tex..., chapter7.tex.
To use .dvi files, copy chapter1.dvi, chapter2.dvi, ...
chapter7.dvi to your host. That's all you need.
Organization of source files (Chapters 1 - 5, concepts)
1. Each section of each chapter is in a separate file.
2. The files are named sxy00.zzz where the letters are as
follows:
s = "s"
x = chapter number
y = section number
00 = "00"
zzz = name of section; most of the time, this is the
complete name; the exception is when the name is too long
for my file system.
3. The files chapter1.tex, chapter2.tex ..., chapter5.tex
contain the information to put the sections together into
chapters.
Organization of source files (Chapters 6 and 7, tool
descriptions)
1. Each function, macro, special form, constant, and variable
(called tools) has its own file.
2. The CLtL files are numbered f001.xxx through f722.xxx
where xxx (can be longer than 3 characters) is the name of
the tool. The tools are ordered alphabetically;
non-alphabetic tool names or parts of tool names generally
precede alphabetic ones.
!
Page 2
3. In some cases the tool's name contains an illegal
character for my file system. In that case you will see
the character spelled out in the filename as follows:
star = "*"
plus = "+"
eqsign = "="
minus = "-"
var = this is the variable of the two tools that have the
same name, e.g. + is a function and + is a variable. The
function + is named "plus" (filename is f005.plus). The
variable + is named "plusvar" (filename is f006.plusvar).
slash = "/"
lessthan = "<"
gtrthan = ">"
4. Starting with f750.xxx are tools that have been added via
clean-up and compiler issues. There is no special
ordering for these tools.
5. Starting with f800.xxx are the tools that are part of the
condition system. They are ordered alphabetically. Many
duplicate tools that are in f001 - f722. Of course the
obsolete versions will be deleted from the directory after
the first review of the condition system has been
completed.
6. Starting with f900.xxx are the tools that are part of
CLOS. They are also ordered alphabetically and there are
also entries that duplicate entries in the f001 - f722
files.
7. The proper files in the proper alphabetic order are
included to be processed in the chapter6.tex and
chapter7.tex files. Also, there are files that group the
tools according to their ordering in CLtL. The files have
names like characters.tex, arrays.tex, ... and correspond
to the chapters in CLtL that contain tool descriptions.
∂21-Feb-89 0755 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU Proposed CSD statement on censorship of rec.humor.funny
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Feb 89 07:55:25 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 21 Feb 89 07:51:13-PST
Message-ID: <E3AzL@SAIL.Stanford.EDU>
Date: 20 Feb 89 2010 PST
From: John McCarthy <JMC@SAIL.Stanford.EDU>
Subject: Proposed CSD statement on censorship of rec.humor.funny
To: faculty@SCORE.STANFORD.EDU
The characteristics of newsgroups distributed through
computer networks are in our area of expertise. If there is
any matter in which the technically competent people should
make statements about the use of the results of their technology,
this is it. Censorship of newsgroups is harmful, likely to
require an active bureaucracy unless the new technology is
to be given up entirely, and very likely to be evaded even
then. Therefore, the Computer Science Department should take
a position and transmit it to the Steering
Committee of the Academic Senate for retransmission to whatever
committee they refer the matter to and ultimately to the Senate
itself. The following is the statement of protest that has
been transmitted to the Administration with 120 signatures. I
have added a sentence referring to the Department's own computers.
I recommend that we adopt it or something like it.
Statement of Protest about the AIR Censorship of rec.humor.funny.
Computer scientists and computer users have been involved in
making information resources widely available since the 1960s.
Such resources are analogous to libraries. The newsgroups
available on various networks are the computer analog of
magazines and partial prototypes of future universal computer
libraries. These libraries will make available the information
resources of the whole world to anyone's terminal or personal
computer.
Therefore, the criteria for including newsgroups in computer
systems or removing them should be identical to those for
including books in or removing books from libraries. For this
reason, and since the resource requirements for keeping
newsgroups available are very small, we consider it contrary to
the function of a university to censor the presence of newsgroups in
University computers. We regard it as analogous to removing a
book from the library. To be able to read anything subject only
to cost limitations is an essential part of academic freedom.
We therefore think that AIR and SDC should rescind the purge of
rec.humor.funny. The Computer Science Department has also decided
not to censor Department Computers.
∂21-Feb-89 0800 @Score.Stanford.EDU:chandler@polya.Stanford.EDU At today's faculty lunch......
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Feb 89 08:00:45 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 21 Feb 89 07:58:00-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA00787; Tue, 21 Feb 89 07:57:32 -0800
Date: Tue, 21 Feb 1989 7:57:29 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, bureaucrats@score, staff-rep@score
Subject: At today's faculty lunch......
Message-Id: <CMM.0.87.604079849.chandler@polya.stanford.edu>
we'll discuss staff concerns. See you in MJH-146 at 12:15!
∂21-Feb-89 0858 BSCOTT@Score.Stanford.EDU [AS.BTH@Forsythe.Stanford.EDU: Army RFP]
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Feb 89 08:58:40 PST
Date: Tue 21 Feb 89 08:54:16-PST
From: Betty Scott <BSCOTT@Score.Stanford.EDU>
Subject: [AS.BTH@Forsythe.Stanford.EDU: Army RFP]
To: Faculty@Score.Stanford.EDU
Message-ID: <12472471874.27.BSCOTT@Score.Stanford.EDU>
FYI. --Betty
---------------
Return-Path: <AS.BTH@Forsythe.Stanford.EDU>
Received: from Forsythe.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 17 Feb 89 16:10:14-PST
Date: Fri, 17 Feb 89 16:10:59 PST
To: bscott@score
From: AS.BTH@Forsythe.Stanford.EDU
Subject: Army RFP
Ruth, Cornelia, Phyllis et al,
Seems like everyone and their brother has been asking about this
RFP from the Army on a High Performance Computing Research Center.
I have written (FAX) for the full RFP, and was told by Patty Cannan
at the Army that no one from Stanford had written for it, hence no
one has received it to date.
Here is what was synopsized in the Nov. 21, 1988 Commerce Business
Daily:
ISA/LABCOM Directorate of Contracting, 2800 Powder Mill Rd.,
Adelphi, MD 20783
ESTABLISHMENT OF ARMY HIGH PERFORMANCE COMPUTING RESEARCH CENTER
(AHPCRC), to include research in High Performance Computing that
requires the acquisition of equipment and software to perform that
research and user support in High Performance Computing. RFP
DAAL02-89-R-9029. DUE 17 APRIL 89. Contact Point: Patty Cannan,
202/394-1088, Contracting Officer, Patricia Silsby, 202/394-3438.
The Army requires the establishment of an Army High Performance
Computing Research Center (AHPCRC). This is a three part
requirement consisting of research in High Performance Computing,
the acquisition of equipment and software to perform that research,
and user support in High Performance Computing. The research and
analysis will address issues appropriate to near term High
Performance Computing, including current Army supercomputer needs,
as well as long term issues, and will provide a basis for advanced
computing techniques within the Army. The research will involve
both systems programming and applications programming with
interdisciplinary research in the efficient utilization of current
advanced performance computers, networks of current computers, and
newly emerging architectures. The research will concentrate on the
development of advanced algorithms and software technology, focusing
on well chosen thrusts in mathematics, computer science and various
associate fields, which contribute to the needs of multiple Army
agencies, without duplicating the work of a specific Army research
activity. Such focused areas will include: simulation of physical
phenomena and the efficient accurate solution of the equations which
govern their behavior, investigation of very large data bases and
info retrieval, visualization and related interactive methods, data
analysis, numerical analysis, implementation of algorithms and
software in a multiplicity of computing environments, and optimal
interfaces in emerging heterogeneous parallel computing
environments. The period of performance for the research effort if
5 years. (ED NOTE: SPO has heard that this is a $254 million
contract.) The contractor shall acquire advanced computing systems
to support the required research. This requirement involves the
acquisition of emerging alternative technology and related
peripherals, for the most advanced state-of-the-art high performance
computing technology. The systems will be installed at the
Contractor's facility. As a part of this requirement the contractor
shall provide operation ad user support consisting of operation and
maintenance of these systems including supporting software and other
equipment required to support a multi-user computing research
environment, initial training, and communications interfaces an user
support. User support will be provided to both local and remote
users, including appropriate users from Govt facilities. On-site
user support services directly related to the Army's production
supercomputers will be provided at two current and one planned Army
supercomputer centers as well as up to three remote sites. The
period of performance for the user support services is a basic
requirement of one year with four options for addl one year periods
of support. This is a competitive procurement with competition
limited to educational institutions or consortiums of educational
institutions. No telephone requests for the sol will be accepted.
To: AS.RMK
cc: AS.CMS, AS.PHU, AS.VGM, AS.CFB, BSCOTT@SCORE, S.STREET@MACBETH, CR.RLB
-------
∂21-Feb-89 1002 HEMENWAY@Score.Stanford.EDU Round 2 Schedule
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Feb 89 10:01:58 PST
Date: Tue 21 Feb 89 09:57:42-PST
From: Sharon Hemenway <HEMENWAY@Score.Stanford.EDU>
Subject: Round 2 Schedule
To: phd-adm@Score.Stanford.EDU
Reply-To: Hemenway@Score.Stanford.EDU
Message-ID: <12472483421.9.HEMENWAY@Score.Stanford.EDU>
Just two weeks to go, everyone!
Here is the schedule agreed to for the Round 2 readings. The entries
in the table are rater numbers.
Pickup Day Batch 1 Batch 2 Batch 3
__________________________________________________
Tues, 2/21 2 3 5 2=Avrahami
Wed, 2/22 5 6 7 3=Chandra
Thurs, 2/23 12 9 10 4=Cheriton
Fri, 2/24 7 12 13 5=Ginsberg
Sat, 2/25 3 4 2 6=Golub
Sun, 2/26 6 7 12 7=Khatib
Mon, 2/27 9 10 11 8=Lam
Tues, 2/28 8 13 4 9=Lansky
Wed, 3/1 4 2 3 10=McCarthy
Thurs, 3/2 11 8 6 11=Moore
Fri, 3/3 10 5 9 12=Roberts
Sat, 3/4 13 11 8 13=Wolf
The final meeting will be at 3:00 on Wednesday, March 8 (hopefully in
MJH 252 but I have to negotiate).
There are 83 applicants (16 of whom are women, in case anyone's
wondering) in Round 2 so there will be 2 batches of 28 folders and one
of 27. (For those of you who weren't at yesterday's meeting, we
decided on 8 Early Admits).
Some groundrules for Round 2:
(1) It is your responsibility to arrange with the readers on either
side of you for pick-up and drop-off of the batches. Feel free to use
my office (or the box outside it) as a drop-off point.
(2) We will put 13 blank rating sheets in each folder today. As you
read and rate them, remove your rating sheet. Your rating sheet
SHOULD NOT be passed on to the next reader. If possible, please give
me your rating sheets as you complete each batch. If you would prefer
to hold onto them until you have read all the folders, please be sure
to get them to me as soon as you have finished the last batch.
(3) The schedule is tight enough that even if you have not had a
chance to read all of the folders (or any), you still must pass them
onto the next reader. I know that there are certain applicants that
some of you do not feel comfortable reading so feel free to skip
them.
Oh, one last thing --while it is just fine that many of you took your
Round 1 rating sheets with you, please do be sure to get them back to
me at the end.
Please let me know if any problems arise.
Sharon
P.S. As requested, here is a list of everyone's e-mail addresses:
PHD-ADM:-
!Gideon Avrahami! Gidi@POLYA.STANFORD.EDU,-
!Rohit Chandra! rohit@POLYA.STANFORD.EDU,-
!David Cheriton! cheriton@PESCADERO.STANFORD.EDU,-
!Michael Genesereth! Genesereth@score
!Matthew Ginsberg! sjg@SAIL.STANFORD.EDU,-
!Gene Golub! golub@PATIENCE.STANFORD.EDU,-
!Sharon R. Hemenway! hemenway@score
!Oussama Khatib! OK@SAIL.STANFORD.EDU,-
!Monica Lam! lam@MOJAVE.STANFORD.EDU,-
!Amy Lansky! LANSKY@SRI.COM,-
!John McCarthy! JMC-LISTS@SAIL.STANFORD.EDU,-
!Bob Moore! bmoore@AI.SRI.COM,-
!Lynn Munday! Munday@score
!Eric Roberts! roberts@DECWRL.DEC.COM,-
!Elizabeth S Wolf! eswolf@POLYA.STANFORD.EDU
-------
∂21-Feb-89 1021 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu staff and lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Feb 89 10:21:42 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 21 Feb 89 10:18:55-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA08459; Tue, 21 Feb 89 10:15:58 PDT
Date: Tue, 21 Feb 89 10:15:58 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8902211815.AA08459@Tenaya.stanford.edu>
To: faculty@score
Subject: staff and lunch
I'll use this note for two purposes:
1) To express the Department's thanks publicly to Carolyn Tajnai, the
staff of the Computer Forum, Ed Feigenbaum, and the whole Forum
committee and all of the students and others who participated in an
extremely successful Forum meeting last week. To be part of an event
of such excellence should make all of us proud.
2) To remark on the importance of our CSD/CSL staff and to express
thanks for the way they keep our ship running. Carolyn Tajnai and her
staff are currently in the spotlight because of the successful Forum,
but I know the whole Department is appreciative about the efforts of
all of our fine staff. Today, at the faculty lunch, we will be able
to hear from staff about how they see the rest of us and about any
suggestions they might have that will make us all more effective. Do
come!
-Nils
∂21-Feb-89 1053 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Today's Faculty Meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Feb 89 10:53:26 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 21 Feb 89 10:50:25-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA07995; Tue, 21 Feb 89 10:50:00 -0800
Date: Tue, 21 Feb 1989 10:49:57 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score
Subject: Today's Faculty Meeting
Message-Id: <CMM.0.87.604090197.chandler@polya.stanford.edu>
This is remind you of today's faculty meeting to be held in MJH-146 at 4:15.
Also, I do have the vitae's - etc. - on Sturmfels and Tardos. You are
welcome to come by my office and take a look at them before the meeting.
∂21-Feb-89 1101 @Score.Stanford.EDU:chandler@polya.Stanford.EDU ["Joyce R. Chandler" <chandler@polya.stanford.edu> : Today's Faculty
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Feb 89 11:01:44 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 21 Feb 89 10:58:31-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA08647; Tue, 21 Feb 89 10:58:05 -0800
Date: Tue, 21 Feb 1989 10:57:19 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score
Subject: ["Joyce R. Chandler" <chandler@polya.stanford.edu> : Today's Faculty
Meeting ]
Message-Id: <CMM.0.87.604090639.chandler@polya.stanford.edu>
Whoops....I've sent this out to the incorrect list. Please ignore this
message.
---------------
Return-Path: <@Score.Stanford.EDU:chandler@polya.Stanford.EDU>
Received: from Score.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA08183; Tue, 21 Feb 89 10:51:58 -0800
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 21 Feb 89 10:50:25-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA07995; Tue, 21 Feb 89 10:50:00 -0800
Date: Tue, 21 Feb 1989 10:49:57 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score
Subject: Today's Faculty Meeting
Message-Id: <CMM.0.87.604090197.chandler@polya.stanford.edu>
This is remind you of today's faculty meeting to be held in MJH-146 at 4:15.
Also, I do have the vitae's - etc. - on Sturmfels and Tardos. You are
welcome to come by my office and take a look at them before the meeting.
∂21-Feb-89 1108 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Today's Faculty Meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Feb 89 11:08:42 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 21 Feb 89 11:02:10-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA08974; Tue, 21 Feb 89 11:01:44 -0800
Date: Tue, 21 Feb 1989 11:01:33 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: ac@score
Subject: Today's Faculty Meeting
Message-Id: <CMM.0.87.604090893.chandler@polya.stanford.edu>
This is to remind you of today's faculty meeting to be held in MJH-146 at
4:15. Also, I do have the vitae's, etc. on Sturmfels and Tardos. You are
welcome to come by my office and take a look at them before the meeting.
∂21-Feb-89 1118 debra@russell.Stanford.EDU REMINDER-Evening Seminar
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Feb 89 11:18:18 PST
Received: from localhost by russell.Stanford.EDU (4.0/inc-1.0)
id AA16823; Tue, 21 Feb 89 11:19:55 PST
Message-Id: <8902211919.AA16823@russell.Stanford.EDU>
To: evesem@russell.Stanford.EDU
Cc: kuder@russell.Stanford.EDU, debra@russell.Stanford.EDU
Subject: REMINDER-Evening Seminar
Date: Tue, 21 Feb 89 11:19:53 PST
From: Debra Alty <debra@russell.Stanford.EDU>
REMINDER
The next EVENING SEMINAR will be Wednesday, February 22nd @ 7:30 pm in
the CSLI Cordura Conference Room.
Professor Stanley Peters, Linguistics & Symbolic Systems Department,
will be leading the discussion.
The following will be served:
Chicken puffs Cognac
Vegetable Platter Wine
w/dip Beer
Crackers Sparkling Waters
Cappuccino/Amaretto Coffee
Cheesecake Tea
Debra
∂21-Feb-89 1143 acuff@sumex-aim.stanford.edu New disk on file server
Received: from sumex-aim.stanford.edu by SAIL.Stanford.EDU with TCP; 21 Feb 89 11:42:59 PST
Received: from KSL-Mac-62 (KSL-Mac-62.Stanford.EDU) by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA04351; Tue, 21 Feb 89 11:41:21 PST
Message-Id: <2813082269-514740@KSL-Mac-62>
Sender: acuff@ksl-mac-62.stanford.edu
Date: Tue, 21 Feb 89 11:44:29 PST
Reply-To: acuff@sumex-aim.stanford.edu
From: Richard Acuff <acuff@sumex-aim.stanford.edu>
To: aap@sumex-aim.stanford.edu
Subject: New disk on file server
I've added an additional disk brick to X26, the AAP file server. I've increased
the space for files to 106MB from 50MB, and added 4 world load partitions as
follows:
Name Unit Size (KB)
---- ---- ---------
LOD4 4 50,000
LOD7 4 50,000
LOD5 5 40,000
LOD8 5 40,000
These partitions are intended to be used for storing worlds that would otherwise
take a long time to build (eg. those that have large circuits in them), and are
thus easier to build once, store on X26, and download when they're needed on a
simulation machine. X26 should NOT be used for running simulations.
Of course, this configuration can be changed. Please assign the use of the
LODn partitions within the AAP. I suggest someone be asked to act as server to
keep track of what each partition is being used for.
-- Rich
∂21-Feb-89 1310 lansky@ai.sri.com AI-RR Seminar THIS THURSDAY -- 3:15pm -- Jay Weber
Received: from Warbucks.AI.SRI.COM by SAIL.Stanford.EDU with TCP; 21 Feb 89 13:10:01 PST
Received: from venice.ai.sri.com by Warbucks.AI.SRI.COM with INTERNET ;
Tue, 21 Feb 89 12:57:39 PST
Received: by venice.ai.sri.com (3.2/4.16)
id AA07647 for planlunch@ai.sri.com; Tue, 21 Feb 89 12:57:55 PST
Date: Tue, 21 Feb 89 12:57:55 PST
From: lansky@Warbucks.AI.SRI.COM (Amy Lansky)
Message-Id: <8902212057.AA07647@venice.ai.sri.com>
To: planlunch@Warbucks.AI.SRI.COM
Subject: AI-RR Seminar THIS THURSDAY -- 3:15pm -- Jay Weber
VISITORS: Please arrive 5 minutes early so that you can be escorted up
from the E-building receptionist's desk. Thanks!
-----------------------------------------------------------------------
A STATISTICAL APPROACH TO THE QUALIFICATION PROBLEM
Jay Weber (JAY@CS.ROCHESTER.EDU)
University of Rochester
3:15 PM, THURSDAY, February 23
SRI International, Building E, Room EJ228
The Qualification Problem asks how a reasoner can make reasonable
predictions about the future without exploring the impractically many
possibilities dictated by the past. This makes it the central problem
of causal reasoning. Previous work on this problem has concentrated
on its representational side, i.e. the mechanics of drawing and
defeating the defeasible inferences. In this talk, I show how the use
of conditional statistics not only provides a superior
representational solution, but also supports empirical justifications
for which evidence is ``ignored''. I show how the statistical impact
of past properties can be measured and ranked in parallel to
incrementally derive a reasonable body of evidence upon which to base
a prediction. Also, I characterize the kinds of causal laws that can
be reasoned about using efficient local propagation in Pearl's singly
connected Bayesian networks.
∂21-Feb-89 1552 @Score.Stanford.EDU:hayes@arisia.xerox.com Proposed CSD statement on censorship of rec.humor.funny
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Feb 89 15:52:24 PST
Received: from arisia.Xerox.COM by SCORE.STANFORD.EDU with TCP; Tue 21 Feb 89 15:46:04-PST
Received: by arisia.Xerox.COM
(5.59++/IDA-1.2.6) id AA12218; Tue, 21 Feb 89 15:43:26 PST
Date: Tue, 21 Feb 89 15:43:26 PST
From: Pat Hayes <hayes@arisia.xerox.com>
Message-Id: <8902212343.AA12218@arisia.Xerox.COM>
To: JMC@SAIL.STANFORD.EDU
Cc: faculty@SCORE.STANFORD.EDU
In-Reply-To: John McCarthy's message of 20 Feb 89 20:10 PST <E3AzL@SAIL.Stanford.EDU>
Subject: Proposed CSD statement on censorship of rec.humor.funny
Im all in favor of such a statement. Theres no sharp line between
censoring 'offensive' humor and burning 'blasphemous' books ( or even
authors ) .
Pat
∂21-Feb-89 1610 @Score.Stanford.EDU:goldberg@polya.Stanford.EDU Ph.D. program
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Feb 89 16:09:54 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 21 Feb 89 16:05:10-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA29973; Tue, 21 Feb 89 16:03:30 -0800
Date: Tue, 21 Feb 89 16:03:30 -0800
From: Andrew V. Goldberg <goldberg@polya.Stanford.EDU>
Message-Id: <8902220003.AA29973@polya.Stanford.EDU>
To: faculty@score
Subject: Ph.D. program
How about the following system for Ph.D. program examinations:
1. Comps (with the number of areas reduced from the current 15, or may be
with students choosing from some of the "optional" areas).
Comps have grades, but no passing scores.
2. Oral qual: a student presents research results to a committee, which
then asks the students questions on this material as well as on the
comp areas in which the student showed weaknesses. The committee also gets
a letter from the student's advisor summarizing research progress of the
student. Based on the research progress and exam performance, the committee
decides if the student has enough knowledge of the Computer Science and if
he/she is likely to produce an acceptable thesis.
The possible outcomes of the exam are
a. Pass.
b. Conditional pass: the student must meet additional requirements imposed
by the committee to strengthen some areas. (For example, the committee
can recommend the student to take a certain course and get at least "B",
of to re-take a comp and get a score that is within the top half of the
exam group.)
c. Fail. (Everybody gets two chances to take the oral.)
An "area qual" that guarantees breadth on knowledge in the student area of
specialization is also a possibility, but I think students get this breadth
anyway.
The proposed system has the following advantages:
-- it encourages early involvement in research as well as interaction with
an advisor (if you have to take an oral qual within, say, seven quarters,
then by that time you should have some research results, and your advisor
should know who you are).
-- it allows to enforce the minimum amount of knowledge expected from a
Stanford Ph.D. with an ability to tailor this knowledge to individual
cases.
-- with reduced pressure of comps, students will have more time to get involved
in research.
-- although certain amount of administration will be required to conduct oral
quals, this administration should not be too time-consuming, and will be
much more meaningful compared to that of some other proposals to stimulate
research.
--Andy
∂21-Feb-89 1633 @Score.Stanford.EDU:ungar@self Re: Ph.D. program
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Feb 89 16:33:14 PST
Received: from self by SCORE.STANFORD.EDU with TCP; Tue 21 Feb 89 16:28:35-PST
Received: by self (4.0/inc-1.0)
id AA23147; Tue, 21 Feb 89 16:21:39 PST
Date: Tue, 21 Feb 89 16:21:39 PST
From: ungar@self.stanford.edu (David Ungar)
Message-Id: <8902220021.AA23147@self>
To: faculty@score.stanford.edu, goldberg@polya.Stanford.EDU
Subject: Re: Ph.D. program
It sounds reasonable to me.
David
∂21-Feb-89 1734 @Score.Stanford.EDU:jcm@ra.stanford.edu Ph.D. program
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Feb 89 17:34:17 PST
Received: from ra.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 21 Feb 89 17:22:35-PST
Received: by ra.stanford.edu (5.59/25-eef) id AA00908; Tue, 21 Feb 89 17:21:16 PDT
Date: Tue, 21 Feb 89 17:21:16 PDT
From: John Mitchell <jcm@ra.stanford.edu>
Message-Id: <8902220121.AA00908@ra.stanford.edu>
To: faculty@score
Subject: Ph.D. program
I like Andy's proposal. I would like to add a suggestion
to keep the area qual, administered by area. So far, I have
found the MTC qual very effective at insuring that students
have a sufficiently broad exposure to the area, and as a
way of diagnosing the strengths and weaknesses of various
students. If administered properly, the area qual need not
stand in the way of research progres. But I think it is a
good mechanism for checking up on breadth. I do not have any
idea how successful quals are in other areas.
∂21-Feb-89 1937 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU draft extra sentence to precede final paragraph
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Feb 89 19:37:20 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 21 Feb 89 19:35:02-PST
Message-ID: <E3asY@SAIL.Stanford.EDU>
Date: 21 Feb 89 1935 PST
From: John McCarthy <JMC@SAIL.Stanford.EDU>
Subject: draft extra sentence to precede final paragraph
To: faculty@Score.Stanford.EDU
Censorship is not an appropriate tool for preventing or dealing
with offensive behavior.
∂21-Feb-89 2149 X3J13-mailer Source for section 2.4
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 21 Feb 89 21:48:43 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for skona%csilvax@hub.ucsb.edu; id AA09830; Tue, 21 Feb 89 08:11:18 PST
Message-Id: <8902211611.AA09830@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 21 Feb 89 11:09
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Source for section 2.4
%% Slots
\beginsubSection{Introduction to Slots}
An {\word object}
that has {\datatype standard-class} as its {\word metaclass} has zero or
more named {\word slots}.
The {\word slots} of an {\word object} are determined by the {\word class}
of the {\word object}. Each {\word slot}
can hold one value. The {\word name} of a {\word slot} is a
{\datatype symbol} that is syntactically valid for use as a variable
name.
When a {\word slot} does not have a value, the {\word slot} is said to be {\bit
unbound}. When an unbound {\word slot} is read, the generic
function {\function slot-unbound} is invoked. The
system-supplied primary {\word method}
for {\function slot-unbound} signals an error.
The default initial value form for a {\word slot}
is defined by the \hbox{{\keyword
:initform}} slot option. When the {\keyword :initform} form is used to
supply a value, it is evaluated in the lexical environment in which
the {\function defclass} form was evaluated. The {\keyword :initform} along with
the lexical environment in which the {\function defclass} form was evaluated
is called a {\bit captured\/} {\keyword :initform}. See the section
``Object Creation and Initialization'' for more details.
A {\bit local slot\/} is defined to be a {\word slot}
that is visible to exactly
one {\word instance},
namely the one in which the {\word slot} is allocated. A {\bit
shared slot\/} is defined to be a {\word slot} that is visible to more than one
{\word instance} of a given {\word class} and its {\word subclasses}.
A {\word class} is said to define a {\word slot} with a given {\word name} when
the {\function defclass} form for that {\word class}
contains a {\word slot} specifier with
that {\word name}.
Defining a {\word local slot} does not immediately create a {\word slot};
it causes a {\word slot} to be created each time an
{\word instance} of the {\word class} is
created. Defining a {\word shared slot} immediately creates a {\word slot}.
The {\keyword :allocation} slot
option to {\function defclass} controls the kind
of {\word slot} that is defined.
If the value of the {\keyword :allocation} slot
option is {\keyword :instance}, a {\word local slot} is created.
If the value of
{\keyword :allocation} is {\keyword :class}, a {\word shared slot} is created.
A {\word slot} is said to be {\bit accessible\/} in an {\word instance}
of a {\word class} if
the {\word slot} is defined by the {\word class}
of the {\word instance} or is inherited from
a {\word superclass} of that {\word class}.
At most one {\word slot} of a given {\word name} can be
{\word accessible} in an {\word instance}.
A {\word shared slot} defined by a {\word class} is
{\word accessible} in all {\word instances}
of that {\word class}.
A detailed explanation of
the inheritance of {\word slots} is given in the section ``Inheritance of
Slots and Slot Options.''
\endsubSection%{Slots}
\beginsubSection{Accessing Slots}
{\word Slots} can be accessed in two ways: by use of the primitive function
{\function slot-value} and by use of {\word generic functions}
generated by the {\function
defclass} form.
The function {\function slot-value} can
be used with any of the {\word slot} names
specified in the {\function defclass} form to access a specific {\word slot}
{\word accessible} in an {\word instance} of the given {\word class}.
The macro {\function defclass} provides
syntax for generating {\word methods} to
read and write {\word slots}.
If a reader {\word method} is requested, a {\word method} is
automatically generated for reading the value of the {\word slot}, but no
{\word method} for storing a value into it is generated. If a writer {\word
method}
is requested, a {\word method} is automatically generated for storing a value
into the {\word slot}, but no {\word method}
for reading its value is generated. If
an accessor {\word method} is requested,
a {\word method} for reading the value of
the {\word slot} and a {\word method}
for storing a value into the {\word slot} are
automatically generated. Reader and writer {\word methods} are implemented
using {\function slot-value}.
When a reader or writer {\word method} is specified for a
{\word slot}, the name of the
{\word generic function} to which the generated {\word method} belongs is directly
specified. If the {\word name}
specified for the writer {\word method} is the symbol
{\tt name}, the {\word name} of the {\word generic function}
for writing the {\word slot}
is the symbol {\tt name}, and the {\word generic function} takes two
arguments: the new value and the {\word instance}, in that order. If the
{\word name}
specified for the accessor {\word method}
is the symbol {\tt name}, the
{\word name} of the {\word generic function} for reading the {\word slot}
is the symbol {\tt
name\/}, and the {\word name} of the {\word generic function} for writing the
{\word slot} is
the list {\tt (setf name)}.
A {\word generic function}
created or modified by supplying reader, writer, or
accessor {\word slot} options can be treated exactly as an ordinary
{\word generic function}.
Note that {\function slot-value} can be used to read or write the value of a
{\word slot} whether or not reader or writer {\word methods}
exist for that {\word slot}.
When {\function slot-value} is used, no reader or writer {\word methods} are
invoked.
The macro {\function with-slots} can be used to establish a lexical
environment in which specified {\word slots}
are lexically available as if they
were variables. The
macro {\function with-slots} invokes the function {\function
slot-value} to access the specified {\word slots}.
The macro {\function with-accessors} can be used to establish a lexical
environment in which specified {\word slots} are lexically available through
their accessors as if they were variables. The macro {\function
with-accessors} invokes the appropriate accessors to access the
specified {\word slots}.
Any accessors specified by {\function with-accessors} must
already have been defined before they are used.
\endsubSection%{Accessing Slots}
\beginsubsubsection{Inheritance of Slots and Slot Options}
The set of the {\word names} of all {\word slots}
{\word accessible} in an {\word instance} of a {\word class}
$C$ is the union of the sets of {\word names} of {\word slots}
defined by $C$ and its
{\word superclasses}. The structure of an {\word instance}
is the set of {\word names}
of {\word local slots} in that {\word instance}.
In the simplest case, only one {\word class} among $C$ and its
{\word superclasses}
defines a {\word slot} with a given {\word slot} name.
If a {\word slot} is defined by a
{\word superclass} of $C$\negthinspace, the {\word slot} is said to be
inherited. The characteristics of the {\word slot} are determined by the
{\word slot} specifier of the defining {\word class}.
Consider the defining {\word class} for
a slot $S$\negthinspace. If the value of the {\keyword :allocation}
slot
option is {\tt :instance}, then $S$ is a {\word local slot} and each
{\word instance}
of $C$ has its own {\word slot} named $S$ that stores its own value. If the
value of the {\keyword :allocation} slot
option is {\tt :class}, then $S$
is a {\word shared slot}, the {\word class}
that defined $S$ stores the value, and all
{\word instances} of $C$ can access that single {\word slot}.
If the {\keyword
:allocation} slot option is omitted, {\tt :instance} is used.
In general, more than one {\word class} among $C$ and its
{\word superclasses} can
define a {\word slot} with a given {\word name}.
In such cases, only one {\word slot} with
the given name is {\word accessible} in an {\word instance}
of $C$\negthinspace, and
the characteristics of that {\word slot} are
a combination of the several {\word slot}
specifiers, computed as follows:
\beginlist
\itemitem{\bull} All the {\word slot}
specifiers for a given {\word slot} name are ordered
from most specific to least specific, according to the order in $C$'s
{\word class precedence list} of the {\word classes}
that define them. All references
to the specificity of {\word slot} specifiers immediately below refers to this
ordering.
\itemitem{\bull} The allocation of a {\word slot}
is controlled by the most specific
{\word slot} specifier. If
the most specific {\word slot} specifier does not contain an
{\keyword :allocation} slot option, {\tt
:instance} is used. Less specific
{\word slot} specifiers do not affect the allocation.
\itemitem{\bull} The default initial value form for a
{\word slot}
is the value of the {\keyword :initform} slot option in the most
specific {\word slot} specifier that contains one. If no {\word slot} specifier
contains an {\keyword :initform} slot option, the {\word slot}
has no default
initial value form.
\itemitem{\bull} The contents of a {\word slot} will always be of type {\tt
(and} $T\sub 1$ $\ldots$ $T\sub n${\tt )} where $T\sub 1 \ldots T\sub n$ are
the values of the {\keyword :type} slot options contained
in all of the {\word slot}
specifiers. If no {\word slot}
specifier contains the {\keyword :type} slot option, the
contents of the {\word slot} will always be of type {\datatype t}. The result
of attempting to store in a {\word slot}
a value that does not satisfy the {\word type} of the {\word slot} is undefined.
\itemitem{\bull} The set of initialization arguments that initialize a given
{\word slot} is the union of the initialization arguments declared in the {\keyword
:initarg} slot options in all the {\word slot} specifiers.
\itemitem{\bull} The documentation string for a {\word slot} is the value of the
{\keyword :documentation} slot option
in the most specific {\word slot} specifier
that contains one. If no {\word slot} specifier contains a {\keyword
:documentation} slot option, the {\word slot} has no documentation string.
\endlist
A consequence of the allocation rule is that a {\word shared slot} can be
{\word shadowed}. For example, if a class $C\sub 1$ defines
a {\word slot} named $S$
whose value for the {\keyword :allocation} slot option is {\tt :class},
that {\word slot} is {\word accessible}
in {\word instances} of $C\sub 1$ and all of its
{\word subclasses}. However, if $C\sub 2$ is a {\word subclass}
of $C\sub 1$ and also
defines a {\word slot} named $S$\negthinspace, $C\sub 1$'s
{\word slot} is not shared
by {\word instances} of $C\sub 2$ and its {\word subclasses}. When a class
$C\sub 1$ defines a {\word shared slot}, any subclass $C\sub 2$ of $C\sub
1$ will share this single {\word slot}
unless the {\function defclass} form for
$C\sub 2$ specifies a {\word slot} of the same
{\word name} or there is a {\word superclass}
of $C\sub 2$ that precedes $C\sub 1$ in the {\word class precedence list} of
$C\sub 2$ that defines a {\word slot} of the same name.
A consequence of the type rule is that the value of a {\word slot} satisfies
the type constraint of each {\word slot} specifier that contributes to that
{\word slot}. Because the result of attempting to store in a
{\word slot} a value
that does not satisfy the type constraint for the {\word slot} is undefined,
the value in a {\word slot} might fail to satisfy its type constraint.
The {\keyword :reader}, {\keyword :writer}, and {\keyword :accessor}
slot options
create {\word methods} rather than define the characteristics of a {\word
slot}.
Reader and writer {\word methods} are inherited in the sense described in
the section ``Inheritance of Methods.''
{\word Methods} that access {\word slots}
use only the name of the {\word slot} and the {\word type}
of the {\word slot's} value. Suppose a {\word superclass}
provides a {\word method} that
expects to access a {\word shared slot} of a given {\word name},
and a {\word subclass} defines
a {\word local slot} with the same {\word name}.
If the {\word method} provided by the
{\word superclass}
is used on an {\word instance} of the {\word subclass},
the {\word method} accesses
the {\word local slot}.
∂21-Feb-89 2150 X3J13-mailer Source for section 6.1
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 21 Feb 89 21:50:01 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for skona%csilvax@hub.ucsb.edu; id AA09971; Tue, 21 Feb 89 08:12:50 PST
Message-Id: <8902211612.AA09971@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 21 Feb 89 11:10
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Source for section 6.1
%% 6.1 Introduction
Following is information necessary to read the {\word tool}
descriptions in
this chapter and Chapter 7.
\beginsubSection{Notation}
This specification uses an extended Backus Normal Form (BNF) to
describe the syntax of @clisp. This section discusses the syntax of
BNF expressions. The primary extension used is the following:
$$\lbrack\!\lbrack\, O\,\rbrack\!\rbrack$$
An expression of this form will appear whenever a list of elements is
to be spliced into a larger structure and the elements can appear in
any order. The symbol $O$ represents a description of the syntax of
some number of syntactic elements to be spliced; that description must
be of the form
$$O\sub 1\ \vert\ \ldots\ \vert\ O\sub n$$
\noindent where each $O\sub i$ can be either of the form $S$ or of
the form $S${\rm *}. The expression $\lbrack\!\lbrack
O\,\rbrack\!\rbrack$ means that a list of the form
$$(O\sub{i\sub 1}\ldots O\sub{i\sub j})\quad 1\leq j$$
\noindent is spliced into the enclosing expression, such that if $n \neq m$
and $1\leq n,m\leq j$,
then either $O\sub{i\sub n}\neq O\sub{i\sub m}$
or $O\sub{i\sub n} = O\sub{i\sub m} = Q\sub{k}$, where for some
$1\leq k \leq n$, $O\sub{k}$ is of the form $Q\sub{k}${\rm *}.
For example, the expression
(\hbox{{\tt x}}\ {$\lbrack\!\lbrack$}$\,$\hbox{{\tt A}}$\ $
$\vert\ $\hbox{{\tt B}}{\rm *}$\ \vert\ $\hbox{{\tt C}}$\,$
{$\rbrack\!\rbrack$}$\ $\hbox{{\tt y}})
\noindent means that at most one {\tt A}, any number of {\tt B}'s, and
at most one {\tt C} can occur in any order.
It is a description of any of these:
\screen!
(x y)
(x B A C y)
(x A B B B B B C y)
(x C B A B B B y)
\endscreen!
\noindent but not any of these:
\screen!
(x B B A A C C y)
(x C B C y)
\endscreen!
\noindent In the first case, both {\tt A} and {\tt C} appear too often,
and in the second case {\tt C} appears too often.
An indirection extension is introduced in order to make this
new syntax more readable:
$$\downarrow\!O$$
\noindent If $O$ is a non-terminal symbol, the right-hand side
of its definition is substituted for the entire expression
$\downarrow\negthinspace O$. For example, the following BNF is equivalent to
the BNF in the previous example:
(\hbox{{\tt x}}$\ ${$\lbrack\!\lbrack$}$\downarrow\!O\,$
{$\rbrack\!\rbrack$}$\ $\hbox{{\tt y}})
O::= \hbox{{\tt A}}$\ \vert\ $\hbox{{\tt B}}{\rm *}$\ \vert\ $\hbox{{\tt C}}
The syntax description for a generic function describes the
lambda-list of the generic function itself, while the method
signatures describe the lambda-lists of the defined methods.
The syntax description for a function, macro, or special form
describes its parameters.
\beginsubsubsection{Operator description template}
Each {\word operator}
description contains the following information:
\label Name:
What the {\word operator} is called.
\label Syntax:
How to use the {\word operator} in code. For example:
\Defun {F} {x y {\opt} z \key\ k\/}
\noindent This description indicates that the function {\bf F}
has two required parameters, {\arg x\/} and {\arg y}. In addition,
there is an optional parameter {\arg z\/} and a keyword parameter {\arg
k}.
\label Method Signature (optional):
The description of a generic function includes descriptions of the
methods that are defined on that generic function by the standard. A
method signature is used to describe the parameters and
parameter specializers for each method.
Methods defined for the generic function must be of the form described
by the method signature.
\Defmeth {F} {\paren{x class\/} \paren{y t\/} {\opt} z \key\ k\/}
\noindent This signature indicates that this method on the generic function
{\bf F} has two required parameters, {\arg x\/}, which must be an
instance of the class {\it class}, and {\arg y}, which can be any
object. In addition, there is an optional parameter {\arg z\/} and a
keyword parameter {\arg k}. This signature also indicates that this
method on {\bf F} is a primary method and has no qualifiers.
\label Arguments:
The @clisp\ {\word type} or natural language description of
what arguments the
{\word operator} accepts, and information about defaults for optional
arguments.
For {\word special forms} and {\word macros}, their arguments are not
evaluated unless it is explictly stated in their descriptions that they
are evaluated.
\label Values:
The @clisp\ {\word type} or natural language description of
what is
returned by the operator.
\label Description:
A summary of the {\word operator}
and all intended aspects of the {\word operator}, but does not
necessarily have to include explicit reference to all its arguments.
\label Examples:
Examples of use of the {\word
operator}. These examples
are not part of the standard.
\label Side Effects:
Anything that is changed as a result of the
evaluation of the {\word form} containing this {\word operator}.
\label Affected By:
Anything that can affect the result this
{\word operator} produces.
\label Conditions:
Three kinds of information may appear here:
\beginlist
\item{\bull}
Situations which are detected by the {\word operator} and formally signalled.
\item{\bull}
Conditions which are handled by the {\word operator}.
\item{\bull}
Situations which may be detected by the {\word operator}.
\endlist
This field may not include conditions that could
be signalled by calling {\word operators\/} passed to this {\word operator}
as arguments or through dynamic variables.
\label See Also:
List of references to other parts of the
standard where information pertaining to this {\word operator} exists. This
list is not part of the standard.
\label Notes:
Information pertaining to this {\word operator} not
found elsewhere in this description. This information is not part of
the standard.
\endsubsubsection%{Operator description template}
\beginsubsubsection{Variable description template}
Each {\word variable}
description contains the following information:
\beginlist
\label Name:
What the {\word variable} is called.
\label Description:
A summary of the {\word variable}
and all intended aspects of the {\word variable}, but does not
necessarily include all the fields referenced below it.
\label Examples:
Examples of use of the {\word
variable}.
These examples
are not part of the standard.
\label Affected By:
Anything that can affect the value of this variable
including {\word functions} which bind this variable and
{\word functions} which assign this variable.
\label See Also:
List of references to other parts of the
standard where information pertaining to this {\word variable} exists. This
list is not part of the standard.
\label Notes:
Information pertaining to this {\word variable} not
found elsewhere in this description. This information is not part of
the standard.
\endsubsubsection%{Variable description template}
\beginsubsubsection{Other information}
Following are general notes that apply to Chapter 6.
Any argument that is named by a name appearing in the following
list has the meaning specified in this list.
\beginlist
\itemitem{\args}
The arguments required by a {\word function} (usually supplied as an argument
itself).
\itemitem{\array}
See ``Types''.
\itemitem{\boolean}
The symbol @nil\ or any non-@nil\ value.
\itemitem{\chara}
See ``Types''.
\itemitem{\env}
An implementation-defined {\word object} that carries the environment
information necessary for evaluating certain {\word forms}.
\itemitem{\fill-pointer}
A non-negative {\datatype integer} no larger than the total
number of elements in the {\datatype vector}
(as returned by @Funref[array-dimension]\rm);
it is the number of ``active'' or ``filled-in'' elements in the {\datatype
vector}.
The {\word fill pointer} constitutes the ``active length'' of the {\datatype
vector};
all {\datatype vector} elements whose index is less than the
{\word fill pointer} are
active, and the others are inactive.
{\datatype Vector} elements not in the active region are still considered
part of the {\datatype vector}.
\itemitem{\form}
An {\word operator} and its argument list
which is a data {\word object}
meant to be {\word evaluated} as a program
to produce zero or more {\word values} (which are also data {\word objects}).
\itemitem{\fnc}
Code that produces zero or more {\word values}.
See ``Types''.
\itemitem{\integer}
See ``Types''.
\itemitem{\list}
See ``Types''.
\itemitem{\object}
A data structure.
\itemitem{\pack}
The possible ways a package name can be supplied as an argument.
\itemitem{(or pathname stream string)}
The possible ways a pathname name can be supplied as an argument.
\issue{PATHNAME-STREAM}
\path
\endissue{PATHNAME-STREAM}
\itemitem{\simple-vector}
See ``Types''.
\itemitem{\type-spec}
See ``Type Specifiers''.
\itemitem{\undefined}
The value returned by the {\word form} being described is not defined
by this standard. See ``Errors''.
\itemitem{\vector}
See ``Types''.
\endlist
Following are notes that apply to {\datatype sequence} functions:
\itemitem{1.} The variants formed by adding {\function -if}
and {\function -if-not}
to an {\word operator's} name do not take an item,
but instead a one-argument function,
and elements are tested for satisfying or not satisfying the function.
As an example,
{\tt (remove {\arg item} {\arg sequence})}
Also,
{\tt (remove-if \#'numberp {\arg sequence})}
returns a {\arg sequence} from which all numbers have been removed.
%% 14.0.0 10
\itemitem{2.} An element {\arg x} of a {\datatype sequence}
``satisfies the test'' if any of
the following are true:
%% 14.0.0 11
\beginlist
\itemitem{a.}
A {\word function} not suffixed by {\function -if} or {\function -if-not}
was called,
{\arg testfn} was supplied by the keyword {\keyword test}, and
{\tt (funcall {\arg testfn} {\arg item} (funcall {\arg keyfn} {\arg x}))} is true.
\itemitem{b.}
%% 14.0.0 12
A {\word function} not suffixed by {\function -if} or {\function -if-not}
was called,
{\arg testfn} was supplied by the keyword {\keyword :test-not}, and
{\tt (funcall {\arg testfn} {\arg item} (funcall {\arg keyfn} {\arg x}))} is false.
\itemitem{c.}
%% 14.0.0 13
A {\word function} suffixed by {\function -if } was called, and
{\tt (funcall {\arg predicate} (funcall {\arg keyfn} {\arg x}))} is true.
\itemitem{d.}
%% 14.0.0 14
A {\word function} suffixed by {\function -if-not } was called, and
{\tt (funcall {\arg predicate} (funcall {\arg keyfn} {\arg x}))} is false.
\endlist
In each case {\arg keyfn} is the
value of the {\keyword key} argument.
%% 14.0.0 15
In the following function descriptions,
two elements {\arg x} and {\arg y}
taken from {\datatype sequences} ``match'' if
either of the following holds:
%% 14.0.0 16
\beginlist
\itemitem{a.}
{\arg Testfn} was supplied by {\keyword test}
and
{\tt (funcall {\arg testfn} (funcall {\arg keyfn} {\arg x})
(funcall {\arg keyfn} {\arg y}))} is true.
%% 14.0.0 17
\itemitem{b.}
{\arg Testfn} was supplied by {\keyword test-not}, and
{\tt (funcall {\arg testfn} (funcall {\arg keyfn} {\arg x}) (funcall {\arg keyfn}
{\arg y}))} is false.
\endlist
%% 14.0.0 18
The order of the arguments to {\arg testfn} corresponds
to the order in which those arguments (or the {\datatype sequences} containing
those arguments)
were given to the sequence function.
If a sequence function gives two elements from the same
sequence argument to {\arg testfn}, they are given in the same order in
which they appear in the {\datatype sequence}.
\endlist
The font key to be used in Chapters 6 and 7
is as follows:
\beginlist
\itemitem{\arg Argument}
Used to represent {\word operator} arguments.
\itemitem{\datatype Data-type}
Used to represent @clisp\
{\word data types\/}.
\itemitem{\word Defined word}
Used to represent the words whose
definitions appear in the ``Glossary''.
\itemitem{\function Tools}
Used to represent {\word tools}.
\itemitem{\keyword Keywords}
Used to represent {\word keywords\/}.
\endlist
\endsubsubsection%{Other information}
∂21-Feb-89 2151 X3J13-mailer Feb. 21 Letter Ballot
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 21 Feb 89 21:50:56 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for skona%csilvax@hub.ucsb.edu; id AA09708; Tue, 21 Feb 89 08:07:50 PST
Message-Id: <8902211607.AA09708@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 21 Feb 89 11:07
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Feb. 21 Letter Ballot
Digital Equipment Corporation
290 Donald Lynch Blvd.
Marlborough, Mass. 01752
DLB5-2/B10
617-490-8027
Dear Members,
The issues, proposals, and sections of the standard named
below have been mailed to the X3J13 mailing list electronically
and via hardcopy.
The purpose of this ballot is to come to closure on certain
parts of the standard that are either non-controversial, or are
required to be agreed upon before work continues on the standard.
These proposals presumably have been reviewed and debated before
you received this ballot. The nature of the items on this ballot
is that an absolute "no" vote is not possible. If you don't like
the proposals or the sections in the standard, your vote should be
"I" (see below), and you should state your problem and your
proposed fix. If there is a majority of "I" votes, the proposal
or section will be corrected and brought to vote again at the
March meeting. Hopefully that won't be necessary since we have
another 20 or so proposals and sections to vote on at the meeting.
For each proposal and section, please choose one of the
following:
[Y]es: adopt the Proposal or section as is.
[I]f the following condition holds....
[A]bstain
- Who can vote?
Only principals may vote.
- Notes
Your vote must be received by me by March 14, 1989, in
order to be counted.
If you wish to mail your ballot in hardcopy form, please
send it to me at the address in the letterhead.
!
Page 2
- Letter ballot
________________________________________________________________________
Issue or section name | Version | Y | I | A |
------------------------------------------------------------------------
CUT-OFF-DATES | 4 | | | |
------------------------------------------------------------------------
ERROR-TERMINOLOGY | 5 | | | |
------------------------------------------------------------------------
FONTS | 2 | | | |
------------------------------------------------------------------------
TOC | 1 | | | |
------------------------------------------------------------------------
Section 1.8 | 5.8 | | | |
------------------------------------------------------------------------
Section 2.3 | 5.8 | | | |
------------------------------------------------------------------------
Section 2.4 | 5.8 | | | |
------------------------------------------------------------------------
Section 2.5 | 5.8 | | | |
------------------------------------------------------------------------
Section 6.1 | 5.8 | | | |
------------------------------------------------------------------------
Thanks in advance for reviewing these proposals and sections,
Kathy Chapman
∂21-Feb-89 2153 X3J13-mailer Issue: TOC
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 21 Feb 89 21:52:47 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for skona%csilvax@hub.ucsb.edu; id AA09649; Tue, 21 Feb 89 08:07:07 PST
Message-Id: <8902211607.AA09649@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 21 Feb 89 11:06
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: TOC
Issue: TOC
References: Working draft of the standard
Category: Editorial
Edit history: 25-JAN-89, Version 1 by Chapman
Problem Description:
The Table of Contents of the standard has changed several times since
the first one was introduced in November, 1987. One step in finalizing
the standard is to agree on the TOC.
Proposal (TOC:STANDARD)
Chapter 1. Introduction
CONTENTS
1.1 Scope, Purpose, and Application
1.2 Organization of the Document
1.3 Referenced Publications
1.4 Definitions
1.5 Compliance
1.6 Implementation-defined Features
Values
Results
Data Representation and Typing
Program and Control Structure
Comparisons
Numerical Calculations
User Interface
Input/Output
Compiling
Miscellaneous
Programming Environment
1.7 Language Extensions
1.8 Portability Issues
Chapter 2. Objects and Types
CONTENTS
2.1 Introduction
2.2 Types
Type Hierarchy and Relationships
Data Type Definition
Type Specifiers
2.3 Classes
Introduction to Classes
Metaclasses
Standard Metaclasses
Defining Classes
Creating Instances of Classes
Inheritance
Inheritance of Class Options
Examples
Determining the Class Precedence List
Topological Sorting
Examples
Redefining Classes
Modifying the Structure of Instances
Initializing Newly Added Local Slots
Customizing Class Redefinition
Extensions
Integrating Types and Classes
2.4 Slots
Introduction to Slots
Accessing Slots
Inheritance of Slots and Slot Options
2.5 Objects
Object Creation and Initialization
Initialization Arguments
Declaring the Validity of Initialization Arguments
Defaulting of Initialization Arguments
Rules for Initialization Arguments
Shared-Initialize
Initialize-Instance
Definitions of Make-Instance and Initialize-Instance
Changing the Class of an Instance
Modifying the Structure of the Instance
Initializing Newly Added Local Slots
Customizing the Change of Class of an Instance
Reinitializing an Instance
Customizing Reinitialization
Meta-Objects
Standard Meta-objects
Chapter 3. Object Syntax
CONTENTS
3.1 Character Reader
Reader Algorithm
Numbers as tokens
Symbols as tokens
Macro character collection
3.2 Object Syntax
Chapter 4. Evaluation and Compilation
CONTENTS
4.1 Evaluation Model
Introduction
Context and Environment
The Model
Form evaluation
Self-evaluating forms
Symbols as forms
Conses as forms
Return values
Shadowing
Extent
Generic Functions and Methods
Introduction to Generic Functions
Introduction to Methods
Agreement on Parameter Specializers and Qualifiers
Congruent Lambda-Lists for All Methods of a Generic Function
Keyword Arguments in Generic Functions and Methods
Method Selection and Combination
Determining the Effective Method
Standard Method Combination
Declarative Method Combination
Built-in Method Combination Types
Inheritance of Methods
Lambda-expressions
4.2 Compilation
Chapter 5. Other Topics
CONTENTS
5.1 Errors
Error Terminology
Condition System Concepts
Condtion System Data Types
Condtion System Operation
5.2 Input/Output
Files
Character and Binary Input/Output
Loading
5.3 Interface with the Programming Environment
Top level loop
Environment inquiry
Time
5.4 Generalized Reference
Chapter 6. Catalog of Tools (A-M)
A-F plus non-alphabetics
G-M
Chapter 7. Catalog of Tools (N-Z)
N-S
T-Z
Rationale:
The current TOC is a result of a year's worth of meetings and many
discussions of the editorial committee. The organization loosely
follows the CLOS chapters 1 and 2 organization by putting the
concepts first, and followed by an alphabetic listing of the
functions/macros/special forms/variables/constants.
The information that deals with data types is organized according to
the Lisp type hierarchy, and a listing of each language element
that is associated with that data type is located at the end
of each data type description in Chapter 2. These listings are
derived from the contents of the chapters in CLtL.
If we come to the conclusion that the standard should be shortened,
Chapters 6 and 7 can be modified to include fewer tools, and section
6.1 can be modified to reflect movement of some of the non-essential
parts of each description to an appendix.
Current Practice:
CLtL, as well as many other Lisp language specifications,
are organized by data types. The Lucid reference manual's chapters
each deal with a data type, but within those chapters, the information
is organized by concepts followed by an alphabetic listing of
language elements.
CLOS chapters 1 and 2 are organized by concepts first and an
alphabetic listing of language elements next.
Adoption Cost:
None.
Benefits:
The data type organization is useful for describing Lisp, and is therefore
used in chapters 2 and 3. However, categorizing
language elements by the data types they are meant to be used with imposes
an unnecessary structure on the document.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
∂21-Feb-89 2155 X3J13-mailer Issue: FONTS
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 21 Feb 89 21:55:38 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for skona%csilvax@hub.ucsb.edu; id AA09577; Tue, 21 Feb 89 08:05:55 PST
Message-Id: <8902211605.AA09577@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 21 Feb 89 11:05
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: FONTS
Issue: FONTS
References: Working draft of the standard
Category: Clarifiaction
Edit history: 25-JAN-89, Version 1 by Chapman
7-FEB-89, Version 2 by Chapman (added discussion)
Problem Description:
The Common Lisp language description makes use of many commonly-used
English words for both their establish meanings and for special
purposes. Since the standard is required to be unambiguous,
a way was devised to distinguish an English word from special word of the same
name.
Proposal (FONTS:STANDARD)
Following is a list of the types of words that have been chosen for
special fonting and the name of the font used to represent each.
Word type Font name
Objects of type xxx (e.g. symbols) Slanted 10 point
Words in the glossary Italics
Tools in Chapters 6 and 7 Bold 9 point
Words in the keyword package defined by the standard Bold 9 point
Parameters supplied to functions/macros/special forms Sans serif 10 point
Rationale:
If the wording in the standard is unambiguous, users of the
standard will find it much easier to write portable code and
conforming implementations.
Current Practice:
CLtL uses fonting mainly for emphasis and for referring to
parameters in function descriptions.
Adoption Cost:
None.
Benefits:
The English descriptions in the standard will be less ambiguous.
Conversion Cost:
None.
Aesthetics:
The fonts have been reworked several times in order to improve
readability. It still requires some familiarity with the style
in order to discover its utility.
Discussion:
Steele says:
"Looks fine to me."
Rosenking says:
"Lets go with this proposal."
∂21-Feb-89 2201 X3J13-mailer Issue: CUT-OFF-DATES
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 21 Feb 89 22:00:44 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for skona%csilvax@hub.ucsb.edu; id AA09483; Tue, 21 Feb 89 08:05:05 PST
Message-Id: <8902211605.AA09483@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 21 Feb 89 11:04
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: CUT-OFF-DATES
Issue: CUT-OFF-DATES
References: Working draft of the standard
Category: Policy
Edit history: 20-DEC-88, Version 1 by Chapman
9-JAN-89, Version 2 by Chapman
25-JAN-89, Version 3 by Chapman
7-FEB-89, Version 4 by Chapman
Problem Description:
The X3J13 committee has informally agreed that a 12/89 standard is
a doable goal. However, the standard has to be reviewed by a large
number of people outside the X3J13 committee. We must allow plenty
of time for these reviews, and should therefore plan our internal
reviews and "document freeze" accordingly.
Proposal (CUT-OFF-DATES:ESTABLISH)
Item Dates
________________________________________________Final Changes___Letter Ballot__
Format of tool descriptions 11/1/88 2/21/89
Meaning of each item in each tool description 11/1/88 2/21/89
Fonts 2/1/89 2/21/89
Changes via clean-up to existing functions 4/1/89
Adding functions via clean-up 3/15/89
Conformance issues 3/1/89 mtg
Error terms 2/19/89 2/21/89
Changes to TOC 2/19/89 2/21/89
Contents of sections:
Chapter 1. Introduction 4/1/89 n/a
CONTENTS
1.1 Scope, Purpose, and Application 3/1/89 mtg
1.2 Organization of the Document 3/1/89 mtg
1.3 Referenced Publications 3/1/89 mtg
1.4 Definitions 3/1/89 mtg
1.5 Compliance 3/1/89 mtg
1.6 Implementation-defined Features 3/15/89 mtg
Values
Results
Data Representation and Typing
Program and Control Structure
Comparisons
Numerical Calculations
User Interface
Input/Output
Compiling
Miscellaneous
Programming Environment
1.7 Language Extensions 3/1/89 mtg
1.8 Portability Issues 2/19/89 2/21/89
Chapter 2. Objects and Types 4/1/89 4/14/89
CONTENTS
2.1 Introduction 3/15/89 mtg
2.2 Types 3/22/89 mtg
Type Hierarchy and Relationships
Data Type Definition
Type Specifiers
2.3 Classes 2/19/89 2/21/89
Introduction to Classes
Metaclasses
Standard Metaclasses
Defining Classes
Creating Instances of Classes
Inheritance
Inheritance of Class Options
Examples
Determining the Class Precedence List
Topological Sorting
Examples
Redefining Classes
Modifying the Structure of Instances
Initializing Newly Added Local Slots
Customizing Class Redefinition
Extensions
Integrating Types and Classes
2.4 Slots 2/19/89 2/21/89
Introduction to Slots
Accessing Slots
Inheritance of Slots and Slot Options
2.5 Objects 2/19/89 2/21/89
Object Creation and Initialization
Initialization Arguments
Declaring the Validity of Initialization Arguments
Defaulting of Initialization Arguments
Rules for Initialization Arguments
Shared-Initialize
Initialize-Instance
Definitions of Make-Instance and Initialize-Instance
Changing the Class of an Instance
Modifying the Structure of the Instance
Initializing Newly Added Local Slots
Customizing the Change of Class of an Instance
Reinitializing an Instance
Customizing Reinitialization
Meta-Objects
Standard Meta-objects
Chapter 3. Object Syntax 4/14/89 5/14/89
CONTENTS
3.1 Character Reader 4/1/89 4/14/89
Reader Algorithm
Numbers as tokens
Symbols as tokens
Macro character collection
3.2 Object Syntax 4/8/89 4/14/89
Chapter 4. Evaluation and Compilation 5/1/89 5/14/89
CONTENTS
4.1 Evaluation Model 4/14/89 5/14/89
Introduction
Context and Environment
The Model
Form evaluation
Self-evaluating forms
Symbols as forms
Conses as forms
Return values
Shadowing
Extent
Generic Functions and Methods
Introduction to Generic Functions
Introduction to Methods
Agreement on Parameter Specializers and Qualifiers
Congruent Lambda-Lists for All Methods of a Generic Function
Keyword Arguments in Generic Functions and Methods
Method Selection and Combination
Determining the Effective Method
Standard Method Combination
Declarative Method Combination
Built-in Method Combination Types
Inheritance of Methods
Lambda-expressions
4.2 Compilation 4/22/89 5/14/89
Chapter 5. Other Topics 4/1/89 4/14/89
CONTENTS
5.1 Errors 3/15/89 mtg
Error Terminology
Condition System Concepts
Condtion System Data Types
Condtion System Operation
5.2 Input/Output 3/8/89 mtg
Files
Character and Binary Input/Output
Loading
5.3 Interface with the Programming Environment 3/8/89 mtg
Top level loop
Environment inquiry
Time
5.4 Generalized Reference 3/8/89 mtg
Chapter 6. Catalog of Tools (A-M) 6/14/89
A-F plus non-alphabetics 4/1/89 4/14/89
G-M 5/1/89 5/14/89
Chapter 7. Catalog of Tools (N-Z) 6/30/89
N-S 6/1/89 6/14/89
T-Z 6/14/89 6/30/89
Glossary 4/1/89 4/14/89
The following will be decided by a letter ballot mailed on 2/21/89:
This list of cut-off-dates (issue CUT-OFF-DATES)
Table of Contents of the standard (issue TOC)
Error terms (issue ERROR-TERMINOLOGY)
Fonts used for distinguishing special words and phrases (issue FONTS)
The following sections in the standard:
1.8 Portability Issues
2.3 Classes
2.4 Slots
2.5 Objects
6.1 Introduction (Format and meaning of tool descriptions in Chapters 6
and 7)
The following will be decided at the 3/89 meeting:
Conformance issues (the issues presented at the 1/89 meeting)
Chapter 1. Introduction (even though all parts have been voted on,
chapter 1 as a whole should be voted on)
The following sections in the standard:
1.1 Scope, Purpose, and Application
1.2 Organization of the Document
1.3 Referenced Publications
1.4 Definitions
1.5 Compliance
1.6 Implementation-defined Features
1.7 Language Extensions
2.1 Introduction
2.2 Types
5.1 Errors
5.2 Input/Output
5.3 Interface with the Programming Environment
5.4 Generalized Reference
The following will be decided by a letter ballot mailed on 4/14/89:
Chapter 2. Objects and Types (ditto, chapter 1)
Chapter 5. Other Topics (ditto, chapter 1)
Glossary
The following sections in the standard:
3.1 Character Reader
3.2 Object Syntax
Chapter 6, A-F plus non-alphabetics
The following will be decided by a letter ballot mailed on 5/14/89:
Chapter 3. Object Syntax (ditto, chapter 1)
Chapter 4. Evaluation and Compilation (ditto, chapter 1)
The following sections in the standard:
4.2 Compilation
G-M
The following will be decided by a letter ballot mailed on 6/14/89:
Chapter 6. Catalog of Tools (A-M) (ditto, chapter 1)
The following section in the standard:
N-S
The following will be decided by a letter ballot mailed on 6/30/89:
Chapter 7. Catalog of Tools (N-Z) (ditto, chapter 1)
The following section in the standard:
T-Z
All comments received according to this schedule will be incorporated
by 6/30/89. Any comments received after the dates listed above will
only be considered if they are of an extreme nature, if they impact
the correctness of the document. Otherwise the comments will be filed
and reserved for the next standard.
To change these dates, a 2/3 vote of the editorial committee
or a majority vote of X3J13 is required.
Rationale:
In order to complete this standard and move on to the next version,
we need to establish dates after which changes will not be allowed.
Current Practice:
None.
Adoption Cost:
None.
Benefits:
Establishing cut-off dates will encourage reviewers to complete
a thorough review in a timely manner.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
Comment:
Larry Masinter says:
"There are a couple of areas where I expect some further work that might
impact these dates:
a) pathname functions
I'm still hoping to get some cleanup of many of the pathname issues
b) errors signalled, by name
I'm still hoping that we can get at least a partial listing, for each
function, of the possible errors signalled, under what circumstances.
c) pending cleanups
There will probably be 10-15 cleanup issues dealing with ambiguities that
will drag out beyond 3/89. I hope not, but I'm trying to be realistic;
there are just too many "open" issues left."
Jeff Rosenking says:
I agree with the CUT-OFF-DATES proposal and believe that a
strict adherence to it may allow us to complete the standard in
the desired time frame. If an exception situation arises then
the exception clause may be voted on by the editorial committee
and/or X3J13 as a whole; I think this provides enough room for
modification, if it is needed.
One concern I have is on the cut-off-date for the Format of tool
descriptions. The apparent need to modify (shorten) the standard
will most likely require a change in the tool description format.
I personally favor having the present format that we adopted, if
I was drafting the standard for my own use. BUT, since I am not
the only intended user of this standard and since we are not the
only group (country) I agree that we have to consider the
feelings of all those who may use this document.
I will support a modification to the tool formats to extract the
examples field and put them in a library or appendix section. If
addiontal measures need to be taken to "trim" the standard we may
want to limit the tool formats to just include a DESCRIPTION,
SYNTAX, ARGUMENTS and VALUES field, with the other fieldsput into
supplementary volumes of the standard. Perhaps the Japanese, and
also the Germans, English and French, will provide alternative
methods for making the standard more concise. Their input and
agreement, on ANSI Common LISP, will make the standard much more
valuable.
∂21-Feb-89 2201 X3J13-mailer Issue: ERROR-TERMINOLOGY
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 21 Feb 89 22:01:42 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for skona%csilvax@hub.ucsb.edu; id AA09435; Tue, 21 Feb 89 08:04:17 PST
Message-Id: <8902211604.AA09435@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 21 Feb 89 11:04
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: ERROR-TERMINOLOGY
Issue: ERROR-TERMINOLOGY
References: Chapter 5, Section 5.1, Working draft of the standard
CLOS Chapter 1
CLtL Chapter 1, Section 1.2.4
Condition System, Version 18
Category: Clarification
Edit history: 27-DEC-88, Version 1 by Chapman
31-JAN-89, Version 2 by Chapman
6-FEB-89, Version 3 by Chapman, RPG and Barmar comments included
8-FEB-89, Version 4 by Chapman, added more to Current Practice
21-FEB-89, Version 5 by Chapman, added van Roggen and RPG comments
Problem Description:
In CLtL, CLOS and the Condition System, similar but slightly
different language is used to describe
non-normal actions by CL operators. The X3J13 committee needs to
agree on a standard set of terms and their meanings.
Proposal (ERROR-TERMINOLOGY:STANDARD TERMS)
TERM MEANING (including CLtL -> standard conversion)
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
CONFORMING CODE (*) Code that adheres to the following requirements:
(1) Conforming code shall not use any constructions
that are prohibited by the standard.
(2) Conforming code shall not depend on extensions
included in an implementation.
SAFE CODE (*) Code processed with the SAFETY optimization at its
highest setting. SAFETY is a lexical property of code.
UNSAFE CODE (*) Code processed with lower safety levels.
Note: Unsafe code is not necesarily code that does not
do error checking. In many cases it may do less error
checking, but no guarantee that error checking will be
less in unsafe code is expressed or implied.
Implementations are permitted to treat all code as safe
code all the time, by simply ignoring the SAFETY
quality or the entire OPTIMIZE declaration.
IS SIGNALLED An error is signalled in both safe and unsafe code.
Conforming code may rely on the fact that the error
will be signalled in both safe and unsafe code.
Every implementation is required to detect the error
in both safe and unsafe code. For example, "an error
is signalled if UNEXPORT is given a symbol not
accessible in the current package."
SHOULD BE SIGNALLED An error will be signalled in safe code, and an error
might or might not be signalled in unsafe code.
Every implementation is required to detect the error at
least in safe code. When the error is not signalled,
the "consequences are undefined" (see below).
Note: The situation which has been identified as an
error is illegal in all implementations, but some
implementations do not actually detect the situation.
Conforming code known to be safe may rely on the
error's being signalled.
For example, "an error should be signalled if ENDP is
given a non-list argument." (Note that there are no
explicit examples of "should signal an error" in
CLtL outside of the Implementation Notes, from which
this example was taken.)
CONSEQUENCES ARE UNDEFINED The consequences are unpredictable. The consequences
may range from harmless to fatal. No conforming code
can depend on the results or effects. Conforming code
must treat the results and effects as unpredictable.
In places where the words "must", "must not" or "may
not" are used, then "the consequences are undefined"
if the stated requirement is not met, and no specific
consequence is explicitly stated.
For example: CLtL currently says: (page 69) "Once a
name has been declared by DEFCONSTANT to be constant,
any further assignment or binding of that special
variable is an error." This statement would be
transformed to: "Once a name has been declared by
DEFCONSTANT to be constant, any further assignment or
binding of that special variable has undefined
consequences."
Note: A result or effect is unpredictable if it might
vary among implementations or separate invocations
within a single implementation. Theh definition of
a harmless effect is difficult to specify precisely.
It is intended that printing error messages on the
stream *ERROR-OUTPUT* or modifying implementation
data during normal operations are harmless. Allocating
storage, invoking a garbage collector, and re-hashing
are prototypicl examples of things that have harmless
effects. In general, an effect is harmless is if does
not cause the implementation to halt or otherwise enter
an inconsistent state.
An effect is fatal if it causes the implementation to
halt or destroys user, implementation, or system data.
For example, leaving the file system in an inconsistent
state is considered fatal. Other unpredictable effects
include entering the debugger or destroying a user data
structure.
If code depends on a harmless effect, then the result
can be fatal. This is why conforming code may not
depend on such effects.
Implementations are permitted to do anything in this
situation.
RETURN VALUES ARE UNSPECIFIED Only the number and nature of the return values
of a construct are not well specifiedbut any
side-effect and transfer-of-control behavior is well
specified. For example, if the return values of some
function F are unspecified, then an expression such as
(length (list (F))) is still well-specified because it
does not rely on any particular aspect of the value or
values returned by F.
CONSEQUENCES ARE UNSPECIFIED The consequences are unpredictable but harmless.
Implementations are permitted to specify the
consequences of this situation. No conforming code may
depend on the results or effects of this situation,
and all conforming code is required to treat the
results and effects of this situation as unpredictable
but harmless. For example, ``the consequences of the
garbage collector when invoked are unspecified.''
IMPLEMENTATIONS MAY BE EXTENDED An implementation is free to treat
the situation in ANY ONE of the following ways:
(1)When the situation occurs, an error is signalled at
least in safe code,
OR
(2)When the situation occurs, the "consequences are
undefined",
OR
(3)When the situation occurs, the consequences are
defined.
Also, no conforming code can depend on the results or
effects of this situation, and all conforming code must
treat the results and effects of the situation as
undefined. Implementations are permitted to do anything
in this situation. For example, "implementations may be
extended to define other type specifiers to have a
corresponding class."
Note: Users should consult the implementation reference
manual to determine the results or effects of this
situation, but should never depend on the results or
effects of this situation in code to be run on other
implementations.
FREE TO EXTEND THE SYNTAX Implementations are permitted to define unambiguous
extensions to the syntax of the construct being
described. No conforming code can depend on this
extension. All conforming code is required to treat
the syntax as meaningless. The standard may disallow
certain extensions while allowing others. For example,
"no implementation is free to extend the syntax of
DEFCLASS."
WARNING IS ISSUED A warning is issued, as described in WARN, in both safe
and unsafe code and when the situation is detected by
the compiler. Conforming code may rely on the fact
that a warning will be issued in both safe and unsafe
code and when the situation is detected by the compiler.
Every implementation is required to detect this
situation in both safe and unsafe code and when the
situation is detected by the compiler. The presence of
a warning will in no way alter the value returned by
the form which caused the situation to occur. For
example, "a warning is issued by the compiler if a
declaration specifier is not one of those defined in
Chapter 9 of CLtL and has not been declared in a
DECLARATION declaration."
WARNING SHOULD BE ISSUED A warning may be issued. Conforming code may not rely
on the fact that a warning will be issued. If the
situation is detected by the compiler, a warning may or
may not be issued, depending on the implementation.
The presence of a warning will in no way alter the
value returned by the form which caused the situation
to occur. For example, (paraphrasing from CLtL, p. 160)
"a warning should be issued by a compiler if a variable
declared to be ignored is ever referred to or is also
declared special, or if a variable is lexical, never
referred to, and not declared to be ignored."
(*) means this term is used to define other terms in this proposal,
not explicitly used in the standard.
Rationale:
For the standard to be an exact specification, terminology must be
defined and agreed upon.
Current Practice:
CLtL uses "is signalled", "should be signalled", "is an error",
"a warning is issued", and "a warning should be issued".
It also uses "is not permitted", "is desireable that", "is not legitimate",
"is illegal", and "should be" (not associated with "signalled"),
"must be", "must not", as well as other such terms.
The definition of "is an error" in CLtL has come to mean "is
allowed" in places where implementations typically extend the language.
CLOS and the Condition System use "is undefined" "is unspecified",
"may be extended", "free to extend the syntax", and "return values are
undefined".
Adoption Cost:
The cost of adopting this terminology will be mostly associated with the
change from "is an error" to some other more specific terminology
from the above list (typically "is an error" -> "is undefined").
Benefits:
Specific terminology will disambiguate function descriptions which
will save implementor's time and decrease user frustration. Users should
be able to write more portable code if the specification is exact.
Conversion Cost:
See Adoption Cost.
Aesthetics:
None.
Discussion:
Barmar comments:
"... I still hate giving the synonyms "undefined" and "unspecified"
different meanings in the standard, but I've given up on that issue."
RPG responds:
"This point is important. In looking over all intended uses of one over the
other, almost all the time we will be saying that something is undefined
when we want people to not use it because the effects could get you, while
we will be saying that values are unspecified. Other times we will be
saying that whether or not something happens is unspecified.
I doubt we will be able to settle this without fine tuning as we see
the effects in the document."
RPG also says:
Many people seem to believe that saying something is harmless is a useless
thing to say in the standard. If we were to drop this term, then every
time we are ``explicitly vague'' a valid possibility is that a fatal error
can occur. How is it any better to say that what happens when some
operation happens is ``explictly vague''? Also, to try to enumerate a
a set of alternatives presumes we are able to forsee all implementation
technologies, which is simply not possible.
To be more explicit, it is valid to specify what can happen if an illegal
operation is performed. If we are not able to list all such effects, users
can have two questions: Do *I* have to worry about detecting that my
program is about to perform this action because my run will be trashed, or
can I simply let it happen without worry? ``Undefined'' and
``unspecified'' are the terms that anwer these questions.
People have asked what happens if *read-base* is changed, is that
harmless? Well, for one thing changing that is never claimed to be among
the things whose effects is unspecified. Second, the other clauses in the
definition must be read at the same time as you read the one about
harmless effects: programs that depend on the effects are not conforming.
Because *read-base* is something explicitly to depend upon, any change to
it behind your back is not harmless.
Certainly in the definition of harmless effects we can explicitly
rule out unspecified changes to things like *read-base* (we can enumerate
them if you like).
People seem to feel that if we cannot with mathematical precision define a
term we should not use it. The attitude to head in that direction is good,
but if you want to go all the way, we are sadly many years away from a
suitable draft. When I read the current draft (and CLtL for that matter) I
find that almost every paragraph requires my detailed knowledge of Lisp
(and sometimes Lisp implementation technology) to understand. Therefore,
we cannot hope for a self-contained document.
∂21-Feb-89 2149 X3J13-mailer Source for section 1.8
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 21 Feb 89 21:46:38 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for skona%csilvax@hub.ucsb.edu; id AA09753; Tue, 21 Feb 89 08:08:26 PST
Message-Id: <8902211608.AA09753@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 21 Feb 89 11:08
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Source for section 1.8
%%Portability Issues
Following is a list of situations which are known to cause portability
problems between implementations:
\beginlist
%% 5.1.4 3
\item{\bull} {\word Macros}
provided by an {\word implementation} may expand
into code that is not portable among differing {\word implementations}.
\item{\bull} {\datatype Floating}-point numbers
\item{\bull} Implementation-dependent sizes
\item{\bull} Conditions
\item{\bull} Declarations
\item{\bull} Files: treatment of {\datatype pathnames}
native syntax, actual
files present
\item{\bull} {\datatype Packages}
\item{\bull} Deliberate non-portability: {\tt #+}, {\tt #-}
\item{\bull} Extended syntax for some
{\word macros} and {\word special forms}, e.g. {\function if}
\item{\bull} Extended argument syntax for some {\word functions},
e.g. non-standard
{\function open} keywords
\item{\bull} Extended functionality of {\word operators} -
allowing arguments not required by the
standard. e.g. {\tt (string pathname)} and {\tt (intern string package-name)}
\item{\bull} Extended {\function format} operations
\item{\bull} File system capabilities
\item{\bull} I/O to a terminal
\endlist
∂21-Feb-89 2208 X3J13-mailer Source for section 2.5
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 21 Feb 89 22:07:48 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for skona%csilvax@hub.ucsb.edu; id AA09989; Tue, 21 Feb 89 08:14:05 PST
Message-Id: <8902211614.AA09989@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 21 Feb 89 11:10
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Source for section 2.5
%%Objects
\beginsubSection{Object Creation and Initialization}
The generic function {\function make-instance} creates and returns a new
{\word instance} of a {\word class}.
The first argument is a {\word class} or the {\word name} of a
{\word class},
and the remaining arguments form an {\bit initialization argument
list}.
The initialization of a new {\word instance} consists of several distinct
steps, including the following: combining the explicitly supplied
initialization arguments with default values for the unsupplied
initialization arguments, checking the validity of the initialization
arguments, allocating storage for the {\word instance}, filling
{\word slots} with
values, and executing user-supplied {\word methods} that perform additional
initialization. Each step of {\function make-instance} is implemented by a
{\word generic function}
to provide a mechanism for customizing that step. In
addition, {\function make-instance} is itself a {\word generic function}
and thus
also can be customized.
The \OS\ specifies system-supplied primary {\word methods} for each step and
thus specifies a well-defined standard behavior for the entire
initialization process. The standard behavior provides four simple
mechanisms for controlling initialization:
\beginlist
\itemitem{\bull} Declaring a {\datatype symbol}
to be an initialization argument for a
{\word slot}. An initialization argument is declared by using the {\keyword
:initarg} slot
option to {\function defclass}. This provides a mechanism
for supplying a value for a {\word slot} in a call to {\function make-instance}.
\itemitem{\bull} Supplying a default value form for an initialization
argument. Default value forms for initialization arguments are
defined by using the {\keyword :default-initargs} class
option to {\function
defclass}. If an initialization argument is not explicitly provided
as an argument to {\function make-instance}, the default value form is
evaluated in the lexical environment of the {\function defclass} form that
defined it, and the resulting value is used as the value of the
initialization argument.
\itemitem{\bull} Supplying a default initial value form for a {\word slot}.
A
default initial value form for a {\word slot} is defined by using the {\keyword
:initform} slot
option to {\function defclass}. If no initialization
argument associated with that {\word slot}
is given as an argument to {\function
make-instance} or is defaulted by {\keyword :default-initargs}, this
default initial value form is evaluated in the lexical environment of
the {\function defclass} form that defined it, and the resulting value is
stored in the {\word slot}.
The {\keyword :initform} form for a {\word local slot} may be
used when creating an {\word instance}, when updating an
{\word instance} to conform
to a redefined {\word class},
or when updating an {\word instance} to conform to the
definition of a different {\word class}.
The {\keyword :initform} form for a {\word shared
slot} may be used when defining or re-defining the {\word class}.
\itemitem{\bull} Defining {\word methods}
for {\function initialize-instance} and {\function
shared-initialize}. The slot-filling behavior described above is
implemented by a system-supplied primary {\word method} for {\function
initialize-instance} which invokes {\function shared-initialize}. The
generic function {\function shared-initialize} implements the parts of
initialization shared by these four situations: when making an
{\word instance},
when re-initializing an {\word instance}, when updating an {\word instance}
to conform to a redefined {\word class},
and when updating an {\word instance} to
conform to the definition of a different {\word class}. The system-supplied
primary {\word method} for {\function shared-initialize}
directly implements the
slot-filling behavior described above, and {\function initialize-instance}
simply invokes {\function shared-initialize}.
\endlist
\beginsubsubsection{Initialization Arguments}
An initialization argument controls {\word object} creation and
initialization. It is often convenient to use keyword {\datatype symbols}
to name
initialization arguments, but the {\word name} of an initialization argument
can be any {\datatype symbol},
including {\tt nil}. An initialization argument
can be used in two ways: to fill a {\word slot} with a value or to provide an
argument for an initialization {\word method}. A single initialization
argument can be used for both purposes.
An {\bit initialization argument list\/} is a list of alternating
initialization argument names and values. Its structure is identical
to a property list and also to the portion of an argument list
processed for {\keyword \&key} parameters. As in those lists, if an
initialization argument name appears more than once in an
initialization argument list, the leftmost occurrence supplies the
value and the remaining occurrences are ignored. The arguments to
{\function make-instance} (after the first argument) form an {\word initialization
argument list}. Error-checking of initialization argument names is
disabled if the keyword argument pair whose keyword is {\keyword
:allow-other-keys} and whose value is non-{\tt nil} appears in the
{\word initialization argument list}.
An initialization argument can be associated with a {\word slot}.
If the
initialization argument has a value in the {\word initialization argument
list}, the value is stored into the {\word slot}
of the newly created {\word object},
overriding any {\keyword :initform} form associated with the {\word slot}. A
single initialization argument can initialize more than one {\word slot}. An
initialization argument that initializes a {\word shared slot} stores its
value into the {\word shared slot}, replacing any previous value.
An initialization argument can be associated with a {\word method}. When an
{\word object} is created and a particular initialization argument is
supplied, the generic functions {\function initialize-instance}, {\function
shared-initialize}, and {\function allocate-instance} are called with that
initialization argument's name and value as a keyword argument pair.
If a value for the initialization argument is not supplied in the
{\word initialization argument list}, the {\word method's}
{\word lambda-list} supplies a
default value.
Initialization arguments are used in four situations: when making
an {\word instance}, when re-initializing an {\word instance},
when updating an {\word instance} to
conform to a redefined {\word class},
and when updating an {\word instance} to conform
to the definition of a different {\word class}.
Because initialization arguments are used to control the creation and
initialization of an {\word instance} of some particular
{\word class}, we say that an
initialization argument is ``an initialization argument for'' that
{\word class}.
\endsubsubsection%{Initialization Arguments}
\beginsubsubsection{Declaring the Validity of Initialization Arguments}
Initialization arguments are checked for validity in each of the four
situations that use them. An initialization argument may be valid in
one situation and not another. For example, the system-supplied
primary {\word method}
for {\function make-instance} defined for the class {\datatype
standard-class} checks the validity of its initialization arguments
and signals an error if an initialization argument is supplied that is
not declared as valid in that situation.
There are two means for declaring initialization arguments valid.
\beginlist
\itemitem{\bull} Initialization arguments that fill {\word slots}
are declared as
valid by the {\keyword :initarg} slot
option to {\function defclass}. The {\keyword
:initarg} slot
option is inherited from {\word superclasses}. Thus the set of
valid initialization arguments that fill {\word slots} for a {\word class} is the
union of the initialization arguments that fill {\word slots} declared as
valid by that {\word class} and its {\word superclasses}.
Initialization arguments
that fill {\word slots} are valid in all four contexts.
\itemitem{\bull} Initialization arguments that supply arguments to {\word
methods}
are declared as valid by defining those {\word methods}. The keyword name of
each keyword parameter specified in the {\word method's}
{\word lambda-list} becomes
an initialization argument for all {\word classes} for which the {\word
method} is
applicable. Thus {\word method} inheritance controls the set of valid
initialization arguments that supply arguments to {\word methods}. The
{\word generic functions} for which {\word method}
definitions serve to declare
initialization arguments valid are as follows:
\beginlist
\itemitem{--} Making an {\word instance} of a {\word class}:
{\function allocate-instance},
{\function initialize-instance}, and {\function shared-initialize}.
Initialization arguments declared as valid by these {\word methods} are
valid when making an {\word instance} of a {\word class}.
\itemitem{--} Re-initializing an {\word instance}: {\function reinitialize-instance}
and {\function shared-initialize}.
Initialization arguments declared as valid by these {\word methods} are
valid when re-initializing an {\word instance}.
\itemitem{--} Updating an {\word instance} to conform to a redefined
{\word class}:
{\function update-instance-for-redefined-class} and {\function shared-initialize}.
Initialization arguments declared as valid by these {\word methods} are
valid when updating an {\word instance} to conform to a redefined {\word
class}.
\itemitem{--} Updating an {\word instance} to conform to the definition of a
different {\word class}:
{\function update-instance-for-different-class} and {\function
shared-initialize}.
Initialization arguments declared as valid by these {\word methods} are
valid when updating an {\word instance} to conform to the definition
of a different {\word class}.
\endlist
\endlist
The set of valid initialization arguments for a {\word class} is the set of
valid initialization arguments that either fill {\word slots} or supply
arguments to {\word methods}, along with the predefined initialization
argument {\keyword :allow-other-keys}. The default value for {\keyword
:allow-other-keys} is {\tt nil}. The meaning of {\keyword
:allow-other-keys} is the same as when it is passed to an ordinary
{\word function}.
\endsubsubsection%{Declaring the Validity of Initialization Arguments}
\beginsubsubsection{Defaulting of Initialization Arguments}
A default value {\word form} can be supplied for an initialization
argument by using the {\keyword :default-initargs} {\word class} option. If an
initialization argument is declared valid by some particular {\word class},
its default value form might be specified by a different {\word class}.
In this case {\keyword :default-initargs} is used to supply a default value
for an inherited initialization argument.
The {\keyword :default-initargs} option is used only to provide default
values for initialization arguments; it does not declare a {\datatype symbol}
as a
valid initialization argument name. Furthermore, the {\keyword
:default-initargs} option is used only to provide default values for
initialization arguments when making an {\word instance}.
The argument to the {\keyword :default-initargs} class
option is a list of
alternating initialization argument names and {\word forms}.
Each {\word form} is the
default value form for the corresponding initialization
argument. The default value {\word form} of an initialization
argument is used and evaluated only if that initialization argument
does not appear in the arguments to {\function make-instance} and is not
defaulted by a more specific {\word class}. The default value {\word form} is
evaluated in the lexical environment of the {\function defclass} form that
supplied it; the resulting value is used as the initialization
argument's value.
The initialization arguments supplied to {\function make-instance} are combined
with defaulted initialization arguments to produce a {\bit
defaulted initialization argument list}. A {\word defaulted initialization
argument list} is a list of alternating initialization argument names and
values in which unsupplied initialization arguments are defaulted and in
which the explicitly supplied initialization arguments appear earlier in
the list than the defaulted initialization arguments. Defaulted
initialization arguments are ordered according to the order in the {\word
class
precedence list} of the {\datatype classes} that supplied the default values.
There is a distinction between the purposes of the {\keyword
:default-initargs} and the {\keyword :initform} options with respect to the
initialization of {\word slots}. The {\keyword :default-initargs}
class option
provides a mechanism for the user to give a default value {\word form}
for an initialization argument without knowing whether the
initialization argument initializes a {\word slot}
or is passed to a {\word method}.
If that initialization argument is not explicitly supplied in a call
to {\function make-instance}, the default value {\word form} is used, just
as if it had been supplied in the call. In contrast, the {\keyword
:initform} slot option provides a mechanism for the user to give a
default initial value form for a {\word slot}. An {\keyword :initform} form is
used to initialize a {\word slot} only if no initialization argument
associated with that {\word slot} is given as an argument to {\function
make-instance} or is defaulted by {\keyword :default-initargs}.
The order of evaluation of default value {\word forms} for initialization
arguments and the order of evaluation of {\keyword :initform} forms are
undefined. If the order of evaluation is important, {\function
initialize-instance} or {\function shared-initialize} {\word methods}
should be used
instead.
\endsubsubsection%{Defaulting of Initialization Arguments}
\beginsubsubsection{Rules for Initialization Arguments}
The {\keyword :initarg} slot option may be specified more than
once for a given {\word slot}.
The following rules specify when initialization arguments may be
multiply defined:
\beginlist
\itemitem{\bull} A given initialization argument can be used to
initialize more than one {\word slot} if the same initialization argument name
appears in more than one {\keyword :initarg} slot option.
\itemitem{\bull} A given initialization argument name can appear
in the {\word lambda-list} of more than one initialization {\word method}.
\itemitem{\bull} A given initialization argument name can
appear both in an {\keyword :initarg} slot option and
in the {\word lambda-list}
of an initialization {\word method}.
\endlist
If two or more initialization arguments that initialize
the same {\word slot}
are given in the arguments to {\function make-instance}, the
leftmost of these initialization arguments in the {\word initialization
argument list} supplies the value, even if the initialization arguments
have different names.
If two or more different initialization arguments that
initialize the same {\word slot} have default values and none is given
explicitly in the arguments to {\function make-instance}, the initialization
argument that appears in a {\keyword :default-initargs} class
option in the
most specific of the {\word classes} supplies the value. If a single {\keyword
:default-initargs} class option specifies two or more initialization
arguments that initialize the same {\word slot} and none is given explicitly
in the arguments to {\function make-instance}, the leftmost in the {\keyword
:default-initargs} class
option supplies the value, and the values of
the remaining default value {\word forms} are ignored.
Initialization arguments given explicitly in the
arguments to {\function make-instance} appear to the left of defaulted
initialization arguments. Suppose that the classes $C\sub 1$ and
$C\sub 2$ supply the values of defaulted initialization arguments for
different {\word slots}, and suppose that $C\sub 1$ is more specific than
$C\sub 2$; then the defaulted initialization argument whose value is
supplied by $C\sub 1$ is to the left of the defaulted initialization
argument whose value is supplied by $C\sub 2$ in the {\word defaulted
initialization argument list}. If a single {\keyword :default-initargs}
class option supplies the values of initialization arguments for two
different {\datatype slots}, the
initialization argument whose value is specified
farther to the left in the {\keyword :default-initargs} class
option appears
farther to the left in the {\word defaulted initialization argument list}.
If a {\word slot} has both an {\keyword :initform} form and an {\keyword
:initarg} slot option, and the initialization argument is defaulted
using {\keyword :default-initargs} or is supplied to {\function make-instance},
the captured {\keyword :initform} form is neither used nor evaluated.
The following is an example of the above rules:
\screen!
(defclass q () ((x :initarg a)))
(defclass r (q) ((x :initarg b))
(:default-initargs a 1 b 2))
\endscreen!
$$\vbox{\halign{\strut#\hfil&\quad\hfil#\hfil&\quad\hfil#\hfil\cr
{}&\bf Defaulted&{}\cr
\bf Form&\bf Initialization Argument List&\bf Contents of Slot\cr
\noalign{\hrule}
{\tt (make-instance 'r)}&{\tt (a 1 b 2)}&{\tt 1}\cr
{\tt (make-instance 'r 'a 3)}&{\tt (a 3 b 2)}&{\tt 3}\cr
{\tt (make-instance 'r 'b 4)}&{\tt (b 4 a 1)}&{\tt 4}\cr
{\tt (make-instance 'r 'a 1 'a 2)}&{\tt (a 1 a 2 b 2)}&{\tt 1}\cr}}$$
\endsubsubsection%{Rules for Initialization arguments}
\beginsubsubsection{Shared-Initialize}
The generic function {\function shared-initialize} is used to fill the {\word
slots}
of an {\word instance}
using initialization arguments and {\keyword :initform}
forms when an {\word instance} is created, when an
{\word instance} is re-initialized,
when an {\word instance}
is updated to conform to a redefined {\word class}, and when
an {\word instance} is updated to conform to a different {\word class}.
It uses
standard {\word method} combination. It takes the following arguments: the
{\word instance} to be initialized, a
specification of a set of {\word names} of {\word slots}
{\word accessible} in that {\word instance}, and any number of initialization
arguments. The arguments after the first two must form an {\word initialization
argument list}.
The second argument to {\function shared-initialize} may be one of the following:
\beginlist
\itemitem{\bull} It can be {\datatype list} of {\word slot} names, which specifies
the set of those {\word slot} names.
\itemitem{\bull} It can be {\tt nil}, which specifies the empty set of
{\word slot} names.
\itemitem{\bull} It can be the symbol {\tt t}, which specifies the set of
all of the {\word slots}.
\endlist
There is a system-supplied primary {\word method} for {\function
shared-initialize} whose first parameter specializer is the class {\datatype
standard-object}. This {\word method} behaves as follows on each {\word
slot},
whether shared or local:
\beginlist
\itemitem{\bull} If an initialization argument in the {\word initialization
argument list} specifies a value for that {\word slot}, that value is stored
into the {\word slot}, even if a value has already been stored in the {\word
slot}
before the {\word method} is run.
The affected {\word slots} are independent of which
{\word slots} are indicated by the second argument to {\function shared-initialize}.
\itemitem{\bull} Any {\word slots}
indicated by the second argument that are still
unbound at this point are initialized according to their {\keyword
:initform} forms. For any such {\word slot}
that has an {\keyword :initform} form,
that {\word form} is evaluated in the
lexical environment of its defining {\function
defclass} form and the result is stored into the {\word slot}.
For example,
if a {\keyword :before} method stores a value in the
{\word slot}, the {\keyword
:initform} form will not be used to supply a value for the {\word slot}. If
the second argument specifies a {\word name} that does not correspond to any
{\word slots} {\word accessible}
in the {\word instance}, the results are unspecified.
\itemitem{\bull} The rules mentioned in the section ``Rules for
Initialization Arguments'' are obeyed.
\endlist
The generic function {\function shared-initialize} is called by the
system-supplied primary {\word methods}
for {\function reinitialize-instance}, {\function
update-instance-for-different-class}, {\function
update-instance-for-redefined-class}, and {\function
initialize-instance}. Thus, {\word methods} can be written for {\function
shared-initialize} to specify actions that should be taken in all of
these contexts.
\endsubsubsection%{Shared-Initialize}
\beginsubsubsection{Initialize-Instance}
The generic function {\function initialize-instance} is called by {\function
make-instance} to initialize a newly created {\word instance}. It uses
standard {\word method} combination. {\word Methods} for {\function
initialize-instance} can be defined in order to perform any
initialization that cannot be achieved with the simple {\word slot}-filling
mechanisms.
During initialization, {\function initialize-instance} is invoked
after the following actions have been taken:
\beginlist
\itemitem{\bull} The {\word defaulted initialization argument list}
has been computed by
combining the supplied {\word initialization argument list} with any
default
initialization arguments for the {\word class}.
\itemitem{\bull} The validity of the {\word defaulted initialization argument
list} has been checked. If any of the initialization arguments has not
been declared as valid, an error is signalled.
\itemitem{\bull} A new {\word instance} whose {\word slots}
are unbound has been created.
\endlist
The generic function {\function initialize-instance} is called with the
new {\word instance} and the defaulted initialization arguments. There is
a system-supplied primary {\word method} for {\function initialize-instance}
whose parameter specializer is the class {\datatype standard-object}. This
{\word method} calls the generic function
{\function shared-initialize} to fill in
the {\word slots} according to the initialization arguments and the {\keyword
:initform} forms for the {\word slots}; the generic function {\function
shared-initialize} is called with the following arguments: the {\word instance},
{\tt t}, and the defaulted initialization arguments.
Note that {\function initialize-instance} provides the {\word defaulted
initialization argument list} in its call to {\function shared-initialize},
so the first step performed by the system-supplied primary {\word method} for
{\function shared-initialize} takes into account both the initialization
arguments provided in the call to {\function make-instance} and the
{\word defaulted initialization argument list}.
{\word Methods} for {\function initialize-instance} can be defined to specify
actions to be taken when an {\word instance} is initialized.
If only {\keyword :after}
methods for {\function initialize-instance} are defined, they will be
run after the system-supplied primary {\word method} for initialization and
therefore will not interfere with the default behavior of {\function
initialize-instance}.
The \OS\ provides two {\word functions} that are useful in the bodies of {\function
initialize-instance} methods. The function {\function slot-boundp}
returns a boolean value that indicates whether a specified {\word slot} has a
value; this provides a mechanism for writing {\keyword :after} methods for
{\function initialize-instance} that initialize {\word slots} only if they have
not already been initialized. The function {\function slot-makunbound}
causes the {\word slot} to have no value.
\endsubsubsection%{INITIALIZE-INSTANCE}
\beginsubsubsection{Definitions of Make-Instance and Initialize-Instance}
The generic function {\function make-instance} behaves as if it were defined as
follows, except that certain optimizations are permitted:
\screen!
(defmethod make-instance ((class standard-class) &rest initargs)
(setq initargs (default-initargs class initargs))
...
(let ((instance (apply #'allocate-instance class initargs)))
(apply #'initialize-instance instance initargs)
instance))
(defmethod make-instance ((class-name symbol) &rest initargs)
(apply #'make-instance (find-class class-name) initargs))
\endscreen!
%This is the code:
%(defmethod make-instance ((class standard-class) &rest initargs)
% (setq initargs (default-initargs class initargs))
% (let* ((proto (class-prototype class))
% (methods
% (append
% (compute-applicable-methods #'allocate-instance `(,class))
% (compute-applicable-methods #'initialize-instance `(,proto))
% (compute-applicable-methods #'shared-initialize `(,proto nil)))))
% (unless
% (subsetp
% (let ((keys '()))
% (do ((plist initargs (cddr plist)))
% ((null plist) keys)
% (push (car plist) keys)))
% (union
% (class-slot-initargs class)
% (reduce #'union (mapcar #'function-keywords methods))))
% (error ...)))
% (let ((instance (apply #'allocate-instance class initargs)))
% (apply #'initialize-instance instance initargs)
% instance))
The elided code in the definition of {\function make-instance} checks the
supplied initialization arguments to determine whether an initialization
argument was supplied that neither filled a {\word slot} nor supplied an argument
to an applicable {\word method}.
%This check could be implemented using the generic
%functions ???{\function class-prototype},??? {\function
%compute-applicable-methods}, {\function
%function-keywords}, and ???{\function class-slot-initargs}. ???
%See Chapter~3 for a
%description of this initialization argument check.
The generic function {\function initialize-instance} behaves as if it were
defined as follows, except that certain optimizations are permitted:
\screen!
(defmethod initialize-instance ((instance standard-object) &rest initargs)
(apply #'shared-initialize instance t initargs)))
\endscreen!
These procedures can be customized at either the Programmer Interface level,
the meta-object level, or both.
Customizing at the Programmer Interface level includes using the {\keyword
:initform}, {\keyword :initarg}, and {\keyword :default-initargs} options to
{\function defclass}, as well as defining {\word methods}
for {\function make-instance}
and {\function initialize-instance}. It is also possible to define
{\word methods} for {\function shared-initialize}, which would be invoked by the
generic functions {\function reinitialize-instance}, {\function
update-instance-for-redefined-class}, {\function
update-instance-for-different-class}, and {\function
initialize-instance}.
The meta-object level supports additional
customization.
%by allowing methods to be defined on {\function
%make-instance},
%???{\bf default-initargs}???, and {\function
%allocate-instance}.
%Chapters~2 and~3 document each of these generic
%functions and the system-supplied primary methods.
Implementations are permitted to make certain optimizations to {\function
initialize-instance} and {\function shared-initialize}.
%The
%description of {\bf shared-initialize} in Chapter~2 mentions the
%possible optimizations.
%Because of optimization, the check for valid initialization arguments
%might not be implemented using the generic functions
%???{\function class-prototype},???
%{\function compute-applicable-methods}, {\function
%function-keywords}, and
%???{\function class-slot-initargs}???. In addition,
%methods for the generic function
%???{\function default-initargs},??? and the
%system-supplied primary methods for
%???{\function allocate-instance}???, {\function
%initialize-instance}, and {\function shared-initialize} might not be called on
%every call to {\function make-instance} or might not receive exactly the
%arguments that would be expected.
\endsubsubsection%{Definitions of MAKE-INSTANCE and Initialize-Instance}
\endsubSection%{Object Creation and Initialization}
\beginsubSection{Changing the Class of an Instance}
The function {\function change-class} can be used to change the {\word class}
of an
{\word instance} from its current class,
$C\sub {\hbox{{\prmseven from}}}$, to a
different class, $C\sub {\hbox{{\prmseven to}}}$; it changes the
structure of the {\word instance} to conform to the definition of the class
$C\sub {\hbox{{\prmseven to}}}$.
Note that changing the {\word class} of an {\word instance}
may cause {\word slots} to be
added or deleted.
When {\function change-class} is invoked on an {\word instance},
a two-step updating
process takes place. The first step modifies the structure of
the {\word instance}
by adding new local {\word slots} and discarding local {\word slots} that
are not specified in the new version of the {\word instance}. The second step
initializes the newly added local {\word slots} and performs any other
user-defined actions. These two steps are further described in the two
following sections.
\beginsubsubsection{Modifying the Structure of the Instance}
In order to make the {\word instance} conform to the class $C\sub
{\hbox{{\prmseven to}}}$, {\word local slots} specified by the class $C\sub
{\hbox{{\prmseven to}}}$ that are not specified by the class $C\sub
{\hbox{{\prmseven from}}}$ are added, and {\word local slots} not specified by
the class $C\sub {\hbox{{\prmseven to}}}$ that are specified by the
class $C\sub {\hbox{{\prmseven from}}}$ are discarded.
The values of {\word local slots} specified by both the class $C\sub
{\hbox{{\prmseven to}}}$ and the class $C\sub {\hbox{{\prmseven
from}}}$ are retained. If such a {\word local slot} was unbound, it remains
unbound.
The values of {\word slots} specified as shared in the class $C\sub
{\hbox{{\prmseven from}}}$ and as local in the class $C\sub
{\hbox{{\prmseven to}}}$ are retained.
This first step of the update does not affect the values of any {\word shared
slots}.
\endsubsubsection%{Modifying the Structure of the Instance}
\beginsubsubsection{Initializing Newly Added Local Slots}
The second step of the update initializes the newly added {\word slots} and
performs any other user-defined actions. This step is implemented by
the generic function {\function update-instance-for-different-class}. The
generic function {\function update-instance-for-different-class} is invoked
by {\function change-class} after the first step of the update has been
completed.
The generic function {\function update-instance-for-different-class} is
invoked on two arguments computed by {\function change-class}. The first
argument passed is a copy of the {\word instance} being updated and is an
{\word instance} of the class $C\sub {\hbox{{\prmseven from}}}$; this copy has
{\word dynamic extent} within the generic function {\function change-class}.
The
second argument is the {\word instance} as updated so far by {\function change-class}
and is an {\word instance} of the class $C\sub {\hbox{{\prmseven to}}}$.
The generic function {\function update-instance-for-different-class} also
takes any number of initialization arguments. When it is called by
{\function change-class}, no initialization arguments are provided.
There is a system-supplied primary {\word method} for {\function
update-instance-for-different-class} that has two parameter
specializers, each of which is the class {\datatype standard-object}. First
this {\word method} checks the validity of initialization arguments and
signals an error if an initialization argument is supplied that is not
declared as valid. (See the section ``Declaring the Validity of
Initialization Arguments'' for more information.) Then it calls the
generic function {\function shared-initialize} with the following arguments:
the {\word instance}, a list of {\word names} of the newly added
{\word slots}, and the
initialization arguments it received.
\endsubsubsection%{Initializing Newly added Local Slots}
\beginsubsubsection{Customizing the Change of Class of an Instance}
{\word Methods}
for {\function update-instance-for-different-class} may be defined
to specify actions to be taken when an {\word instance} is updated. If only
{\keyword :after} methods for {\function update-instance-for-different-class} are
defined, they will be run after the system-supplied primary {\word method} for
initialization and will not interfere with the default behavior of
{\function update-instance-for-different-class}. Because no initialization
arguments are passed to {\function update-instance-for-different-class} when
it is called by {\function change-class},
the {\keyword :initform} forms for {\word slots}
that are filled by {\keyword :before} methods for {\function
update-instance-for-different-class} will not be evaluated by {\function
shared-initialize}.
{\word Methods}
for {\function shared-initialize} may be defined to customize {\word class}
redefinition. See the section ``Shared-Initialize'' for more
information.
\endsubsubsection%{Customizing the Change of Class of an Instance}
\endsubSection%{Changing the Classes of an Instance}
\beginsubSection{Reinitializing an Instance}
The generic function {\function reinitialize-instance} may be used to change
the values of {\word slots} according to initialization arguments.
The process of reinitialization changes the values of some {\word slots} and
performs any user-defined actions. It does not modify the structure
of an {\word instance} to add or delete {\word slots},
and it does not use any {\keyword
:initform} forms to initialize {\word slots}.
The generic function {\function reinitialize-instance} may be called
directly. It takes one required argument, the {\word instance}. It also
takes any number of initialization arguments to be used by {\word methods} for
{\function reinitialize-instance} or for {\function shared-initialize}. The
arguments after the required {\word instance} must form an
{\word initialization
argument list}.
There is a system-supplied primary {\word method} for {\function
reinitialize-instance} whose parameter specializer is the class {\datatype
standard-object}. First this {\word method} checks the validity of
initialization arguments and signals an error if an initialization
argument is supplied that is not declared as valid. (See the section
``Declaring the Validity of Initialization Arguments'' for more
information.) Then it calls the generic function {\function
shared-initialize} with the following arguments: the {\word instance}, {\tt
nil}, and the initialization arguments it received.
\beginsubsubsection{Customizing Reinitialization}
{\word Methods} for {\function reinitialize-instance} may be defined to specify
actions to be taken when an {\word instance} is updated.
If only {\keyword :after}
methods for {\function reinitialize-instance} are defined, they will be run
after the system-supplied primary {\word method} for initialization and
therefore will not interfere with the default behavior of {\function
reinitialize-instance}.
{\word Methods} for {\function shared-initialize} may
be defined to customize {\word class}
redefinition. See the section ``Shared-Initialize'' for more
information.
\endsubsubsection%{Customizing Reinitialization}
\endsubSection%{Reinitializing an Instance}
\beginsubSection{Meta-Objects}
The implementation of the \OS\ manipulates {\word classes},
{\word methods}, and {\word generic
functions}.
The \OS\ contains a set of {\word generic
functions} defined by {\word methods} on {\word classes};
the behavior of those {\word generic
functions} defines the behavior of the \OS.
The {\word instances} of the {\word classes}
on which those {\word methods} are defined are called meta-objects.
%Programming
%at the meta-object protocol level involves defining new classes of
%meta-objects along with methods specialized on these classes.
\beginsubSection{Standard Meta-objects}
The \OS\ supplies a set of meta-objects, called standard
meta-objects. These include the class {\datatype standard-object} and
{\word instances} of the classes {\datatype standard-method}, {\datatype
standard-generic-function}, and {\datatype method-combination}.
\beginlist
\itemitem{\bull}
The class {\datatype standard-method} is the default {\word class} of
{\word methods} defined by the forms {\function defmethod}, {\function
defgeneric}, {\function generic-function}, {\function generic-flet}, {\function
generic-labels}, and {\function with-added-methods}.
\itemitem{\bull}
The class {\datatype standard-generic-function} is the default {\word class} of
{\word generic functions} defined by the forms {\function defmethod},
{\function defgeneric}, {\function generic-function}, {\function generic-flet},
{\function generic-labels}, {\function with-added-methods}, and {\function defclass}.
\itemitem{\bull} The {\word class} named {\datatype standard-object}
is an {\word instance} of
the class {\datatype standard-class} and is a {\word superclass}
of every {\word class} that
is an {\word instance} of {\datatype standard-class}
except itself and {\datatype
structure-class}.
\itemitem{\bull} Every {\word method} combination object is an {\word instance}
of a
{\word subclass} of the class {\datatype method-combination}.
\endlist
\endsubSection%{Standard Meta-objects}
\endSection%{Meta-Objects}
∂21-Feb-89 2209 X3J13-mailer Source for section 2.3
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 21 Feb 89 22:09:26 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for skona%csilvax@hub.ucsb.edu; id AA09793; Tue, 21 Feb 89 08:11:01 PST
Message-Id: <8902211611.AA09793@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
Date: 21 Feb 89 11:09
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Source for section 2.3
%% Classes
\beginsubSection{Introduction to Classes}
A {\bit class\/} is an {\word object}
that determines the structure and behavior
of a set of other {\word objects}, which are called its {\bit instances}.
A {\word class} can inherit structure and behavior from other {\word classes}.
A {\word class} whose definition refers to other {\word classes}
for the purpose of
inheriting from them is said to be a {\bit subclass\/} of each of
those {\word classes}. The {\word classes} that are designated for purposes of
inheritance are said to be {\bit superclasses\/}
of the inheriting {\word class}.
A {\word class} can have a {\bit name}. The function {\function class-name} takes a
{\word class} object and returns its {\word name}.
The {\word name} of an anonymous {\word class} is
{\tt nil}. A {\datatype symbol}
can {\bit name\/} a {\word class}. The function {\function
find-class} takes a {\datatype symbol} and returns the {\word class} that the
{\datatype symbol}
names. A {\word class} has a {\bit proper name\/} if the
{\word name} is a {\datatype symbol}
and if the {\word name} of the {\word class}
names that {\word class}. That is, a class~$C$ has the {\bit proper
name\/}~$S$ if $S=$ {\tt (class-name $C$)} and $C=$ {\tt (find-class
$S$)}. Notice that it is possible for {\tt (find-class $S\sub 1$)}
$=$ {\tt (find-class $S\sub 2$)} and $S\sub 1\neq S\sub 2$.
If $C=$ {\tt (find-class $S$)}, we say that $C$ is the class named
$S$.
A class $C\sub{1}$ is a direct {\bit superclass\/} of a class
$C\sub{2}$ if $C\sub{2}$ explicitly designates $C\sub{1}$ as a
{\word superclass} in its definition. In this case $C\sub{2}$ is a
direct {\bit subclass\/} of $C\sub{1}$. A class $C\sub{n}$ is a {\bit
superclass\/} of a class $C\sub{1}$ if there exists a series of
classes $C\sub{2},\ldots,C\sub{n-1}$ such that $C\sub{i+1}$ is a
direct {\word superclass} of $C\sub{i}$ for $1 \leq i<n$. In this case,
$C\sub{1}$ is a {\bit subclass\/} of $C\sub{n}$. A {\word class} is
considered neither a {\word superclass} nor a {\word subclass}
of itself. That is, if
$C\sub{1}$ is a {\word superclass} of $C\sub{2}$, then $C\sub{1} \neq
C\sub{2}$. The set of {\word classes} consisting of some given
class $C$ along with all of its {\word superclasses} is called ``$C$ and its
superclasses.''
Each {\word class}
has a {\bit class precedence list}, which is a total ordering
on the set of the given {\word class} and its
{\word superclasses}. The total ordering
is expressed as a list ordered from most specific to least specific.
The {\word class precedence list} is used in several ways. In general, more
specific {\word classes} can {\bit shadow}, or override, features that would
otherwise be inherited from less specific {\word classes}. The
{\word method} selection
and combination process uses the {\word class precedence list} to order
{\word methods}
from most specific to least specific.
When a {\word class} is defined, the order
in which its direct {\word superclasses}
are mentioned in the defining form is important. Each {\word class} has a
{\bit local precedence order\/}, which is a list consisting of the
{\word class} followed by its direct
{\word superclasses} in the order mentioned
in the defining {\word form}.
A {\word class precedence list}
is always consistent with the {\word local precedence
order} of each {\word class} in the list.
The {\word classes} in each {\word local precedence
order} appear within the {\word class precedence list} in the same order. If
the {\word local precedence orders} are inconsistent with each other,
no {\word class
precedence list} can be constructed, and an error is signalled.
The {\word class precedence list} and its computation is discussed
in the section ``Determining the Class Precedence List.''
{\word Classes} are organized into a directed acyclic graph. There are
two distinguished {\word classes},
named {\datatype t} and {\datatype standard-object}.
The {\word class} named {\datatype t} has no {\word superclasses}.
It is a {\word superclass} of
every {\word class} except itself.
The {\word class} named {\datatype standard-object} is
an {\word instance} of
the class {\datatype standard-class} and is a {\word superclass} of
every {\word class} that is an
{\word instance} of {\datatype standard-class} except itself.
There is a mapping from the object system {\word class} space into
the {\word type} space. Many of the standard {\word types}
specified in this document have a corresponding
{\word class} that has the same {\word name} as the
{\word type}. Some {\word types} do
not have a corresponding {\word class}. The integration of
the {\word type} and {\word class}
systems is discussed in the section ``Integrating Types and Classes.''
{\word Classes} are represented by {\word objects} that are themselves
{\word instances} of {\word classes}.
The {\word class} of the {\word class} of an {\word object} is termed
the {\bit metaclass\/} of that {\word object}. When no misinterpretation is
possible, the term {\bit metaclass\/} will be used to refer to a {\word
class}
that has {\word instances} that are themselves
{\word classes}. The {\word metaclass}
determines the form of inheritance used by the {\word classes} that are its
{\word instances} and the representation of the
{\word instances} of those {\word classes}.
The \CLOS\ provides a default {\word metaclass},
{\datatype standard-class}, that is
appropriate for most programs.
%The meta-object protocol provides
%mechanisms for defining and using new metaclasses.
Except where otherwise specified, all {\word classes} mentioned in this
standard are {\word instances} of the
class {\datatype standard-class}, all {\word generic
functions} are {\word instances}
of the class {\datatype standard-generic-function},
and all {\word methods} are {\word instances} of the class {\datatype standard-method}.
\endsubSection%{Classes}
%\beginsubsubsection{Metaclasses}
%??? Is the following paragraph necessary in this specification???
%
%The {\bit metaclass\/} of an object is the class of its class. The
%metaclass determines the representation of instances of its instances and
%the forms of inheritance used by its instances for slot descriptions and
%method inheritance. The metaclass mechanism can be used to provide
%particular forms of optimization or to tailor the \CLOS\ for particular
%uses.
%The protocol for defining metaclasses is discussed in the chapter
%``The \CLOS\ Meta-Object Protocol.''
%\endsubsubsection%{Metaclasses}
\beginsubsubsection{Standard Metaclasses}
The \CLOS\ provides a number of predefined {\word metaclasses}.
These include the
classes {\datatype standard-class}, {\datatype built-in-class}, and {\datatype
structure-class}:
\beginlist
\itemitem{\bull}
The class {\datatype standard-class} is the default {\word class} of
{\word classes} defined
by {\function defclass}.
\itemitem{\bull} The class {\datatype built-in-class} is the {\word class} whose
{\word instances} are {\word classes}
that have special implementations with
restricted capabilities. Any {\word class} that corresponds to a standard
{\word type}
might be an {\word instance} of {\datatype built-in-class}.
The predefined {\word type} specifiers that are required to have
corresponding {\word classes}
are listed in Figure {\chapno--\the\capno}. It is
implementation-dependent
whether each of these {\word classes} is implemented as a
{\datatype built-in-class}.
\itemitem{\bull}
All {\word classes} defined by means of {\function defstruct}
are {\word instances} of
{\datatype structure-class}.
\endlist
\endsubsubsection%{Standard Metaclasses}
\beginsubSection{Defining Classes}
The macro {\function defclass} is used to define a new named {\word class}.
%The
%syntax for {\function defclass} is given in Figure??
The definition of a {\word class} includes:
\beginlist
\itemitem{\bull} The {\word name} of the new {\word class}.
For newly defined {\word classes}
this {\word name} is a proper name.
\itemitem{\bull} The list of the direct {\word superclasses}
of the new {\word class}.
\itemitem{\bull} A set of {\bit slot} specifiers. Each {\word slot} specifier
includes the {\word name} of the {\word slot}
and zero or more {\bit slot} options. A
{\word slot} option pertains only to a single {\word slot}.
If a {\word class} definition
contains two {\word slot}
specifiers with the same {\word name}, an error is signalled.
\itemitem{\bull} A set of {\bit class} options.
Each {\word class} option pertains
to the {\word class} as a whole.
\endlist
The {\word slot}
options and {\word class} options of the {\function defclass} form provide
mechanisms for the following:
\beginlist
\itemitem{\bull} Supplying a default initial value {\word form}
for a given {\word slot}.
\itemitem{\bull} Requesting that {\word methods} for {\word generic functions}
be automatically generated for reading or writing {\word slots}.
\itemitem{\bull} Controlling whether a given {\word slot} is shared by
{\word instances}
of the {\word class} or whether each
{\word instance} of the {\word class} has its own {\word slot}.
\itemitem{\bull} Supplying a set of initialization arguments and initialization
argument defaults to be used in {\word instance} creation.
%\itemitem{\bull} Requesting that a constructor function be automatically
%generated for making instances of the new class.
\itemitem{\bull} Indicating that the {\word metaclass}
is to be other than the default.
\itemitem{\bull} Indicating the expected {\word type}
for the value stored in the {\word slot}.
\itemitem{\bull} Indicating the documentation string for the {\word slot}.
\endlist
\endsubSection%{Defining Classes}
\goodbreak
\beginsubSection{Creating Instances of Classes}
The generic function {\function make-instance} creates and returns a new
{\word instance} of a {\word class}.
The \OS\ provides several mechanisms for
specifying how a new {\word instance} is to be initialized. For example, it
is possible to specify the initial values for {\word slots} in newly created
{\word instances}
either by giving arguments to {\function make-instance} or by
providing default initial values. Further initialization activities
can be performed by {\word methods} written for {\word generic functions}
that are
part of the initialization protocol. The complete initialization
protocol is described in the section ``Object Creation and
Initialization.''
\endsubSection%{Creating Instances of Classes}
\beginsubSection{Inheritance}
A {\word class}
can inherit {\word methods}, {\word slots},
and some {\function defclass} options
from its {\word superclasses}.
The following sections describe the inheritance of
{\word methods}, the inheritance of {\word slots} and {\word slot} options,
and the inheritance of
{\word class} options.
\beginsubsubsection{Inheritance of Class Options}
The {\keyword :default-initargs} class option is inherited. The set of
defaulted initialization arguments for a {\word class} is the union of the
sets of initialization arguments supplied in the {\keyword
:default-initargs} class options of the {\word class} and its
{\word superclasses}.
When more than one default initial value {\word form} is supplied for a given
initialization argument, the default initial value {\word form} that is used
is the one supplied by the {\word class} that is most specific according to
the {\word class precedence list}.
If a given {\keyword :default-initargs} class option specifies an
initialization argument of the same {\word name} more than once, an
error is signalled.
\endsubsubsection%{Inheritance of Class Options}
\beginsubsubsection{Examples}
\screen!
(defclass C1 ()
((S1 :initform 5.4 :type number)
(S2 :allocation :class)))
(defclass C2 (C1)
((S1 :initform 5 :type integer)
(S2 :allocation :instance)
(S3 :accessor C2-S3)))
\endscreen!
Instances of the class {\tt C1} have a {\word local slot}
named {\tt S1}, whose default
initial value is 5.4 and whose value should always be a {\datatype number}.
The class {\tt C1} also has a {\word shared slot} named {\tt S2}.
There is a {\word local slot} named {\tt S1}
in {\word instances} of {\tt C2}. The
default initial value of {\tt S1} is 5. The value of {\tt S1} will be
of type {\tt (and integer number)}. There are also {\word local slots} named
{\tt S2} and {\tt S3} in {\word instances} of {\tt C2}. The class {\tt C2}
has a {\word method} for {\tt C2-S3} for reading the value of slot {\tt S3};
there is also a {\word method} for {\tt (setf C2-S3)} that writes the
value of {\tt S3}.
\endsubsubsection%{Examples of Inheritance}
\endsubSection%{Inheritance}
\beginsubSection{Determining the Class Precedence List}
The {\function defclass} form for a {\word class}
provides a total ordering on that
{\word class} and its direct {\word superclasses}.
This ordering is called the {\bit
local precedence order}. It is an ordered list of the {\word class} and its
direct {\word superclasses}. The {\bit class precedence list\/} for a
class $C$ is a total ordering on $C$ and its {\word superclasses}
that is consistent
with the {\word local precedence orders} for each of $C$ and its
{\word superclasses}.
A {\word class} precedes its direct {\word superclasses}, and a
direct {\word superclass}
precedes all other direct {\word superclasses} specified to
its right in the {\word superclasses}
list of the {\function defclass} form. For
every class $C$, define $$R\sub C=\{(C,C\sub 1),(C\sub 1,C\sub
2),\ldots,(C\sub {n-1},C\sub n)\}$$ where $C\sub 1,\ldots,C\sub n$ are
the direct {\word superclasses} of $C$ in the order in which
they are mentioned in the {\function defclass} form. These ordered pairs
generate the total ordering on the class $C$ and its direct
{\word superclasses}.
Let $S\sub C$ be the set of $C$ and its {\word superclasses}. Let $R$ be
$$R=\bigcup\sub{c\in {S\sub C}}R\sub c$$.
The set $R$ may or may not generate a partial ordering, depending on
whether the $R\sub c$, $c\in S\sub C$, are consistent; it is assumed
that they are consistent and that $R$ generates a partial ordering.
When the $R\sub c$ are not consistent, it is said that $R$ is inconsistent.
%This partial ordering is generated by taking the the transitive
%closure of the set $R\cup \{(c,c) \vert c\in {S\sub C}\}$. When
%$(C\sub 1,C\sub 2)\in R$\negthinspace, it is said that $C\sub 1$
%{\bit precedes or equals} $C\sub 2$. Intuitively, $C\sub 1$ precedes
%or equals $C\sub 2$ when $C\sub 1=C\sub 2$ or $C\sub 2$ is a
%superclass of $C\sub 1$.
%
%Recall that a partial ordering of the set $S$ is a relation between
%objects of $S$ that is transitive, reflexive, and antisymmetric. The
%set $\{(c,c) \vert c\in {S\subC}\}$ was added to the transitive
%closure of the set $R$ in order to make the relation reflexive. In
%the remainder of this section the set of precedence relations $R$ and
%not the partial ordering will be used.
To compute the {\word class precedence list} for~$C$\negthinspace,
topologically sort the elements of $S\sub C$ with respect to the
partial ordering generated by $R$\negthinspace. When the topological
sort must select a {\word class} from a set of two or more
{\word classes}, none of
which are preceded by other {\word classes} with respect to~$R$\negthinspace,
the {\word class} selected is chosen deterministically, as described below.
If $R$ is inconsistent, an error is signalled.
\goodbreak
\beginsubsubsection{Topological Sorting}
Topological sorting proceeds by finding a class $C$ in~$S\sub C$ such
that no other {\word class} precedes that element according to the elements
in~$R$\negthinspace. The class $C$ is placed first in the result.
Remove $C$ from $S\sub C$, and remove all pairs of the form $(C,D)$,
$D\in S\sub C$, from $R$\negthinspace. Repeat the process, adding
{\word classes} with no predecessors to the end of the result. Stop when no
element can be found that has no predecessor.
If $S\sub C$ is not empty and the process has stopped, the set $R$ is
inconsistent. If every {\word class} in the finite set of
{\word classes} is preceded
by another, then $R$ contains a loop. That is, there is a chain of
classes $C\sub 1,\ldots,C\sub n$ such that $C\sub i$ precedes
$C\sub{i+1}$, $1\leq i<n$, and $C\sub n$ precedes $C\sub 1$.
Sometimes there are several {\word classes} from $S\sub C$ with no
predecessors. In this case select the one that has a direct
{\word subclass} rightmost in the {\word class precedence list} computed so far.
%Because a direct superclass precedes all other direct superclasses to
%its right, there can be only one such candidate class.
If there is no
such candidate {\word class}, $R$ does not generate a partial ordering---the
$R\sub c$, $c\in S\sub C$, are inconsistent.
In more precise terms, let $\{N\sub 1,\ldots,N\sub m\}$, $m\geq 2$, be
the {\word classes} from $S\sub C$ with no predecessors. Let $(C\sub
1\ldots C\sub n)$, $n\geq 1$, be the {\word class precedence list}
constructed so far. $C\sub 1$ is the most specific {\word class}, and $C\sub
n$ is the least specific. Let $1\leq j\leq n$ be the largest number
such that there exists an $i$ where $1\leq i\leq m$ and $N\sub i$
is a direct {\word superclass} of $C\sub j$; $N\sub i$ is placed next.
The effect of this rule for selecting from a set of {\word classes} with no
predecessors is that the {\word classes} in a simple {\word superclass} chain are
adjacent in the {\word class precedence list} and that {\word classes} in each
relatively separated subgraph are adjacent in the {\word class
precedence list}. For example, let $T\sub 1$ and $T\sub 2$ be subgraphs
whose only element in common is the class $J$\negthinspace. Suppose
that no {\word superclass} of $J$ appears in either $T\sub 1$ or $T\sub 2$.
Let $C\sub 1$ be the bottom of $T\sub 1$; and let $C\sub 2$ be the
bottom of $T\sub 2$. Suppose $C$ is a {\word class} whose direct {\word
superclasses}
are $C\sub 1$ and $C\sub 2$ in that order, then the {\word class precedence
list} for $C$ will start with $C$ and will be followed by all {\word classes}
in $T\sub 1$ except $J$. All the {\word classes} of $T\sub 2$ will be next.
The class $J$ and its {\word superclasses} will appear last.
\endsubsubsection%{Topological Sorting}
\beginsubsubsection{Examples}
This example determines a {\word class precedence list} for the
class {\tt pie}. The following {\word classes} are defined:
\screen!
(defclass pie (apple cinnamon) ())
(defclass apple (fruit) ())
(defclass cinnamon (spice) ())
(defclass fruit (food) ())
(defclass spice (food) ())
(defclass food () ())
\endscreen!
The set $S$~$=$ $\{${\tt pie, apple, cinnamon, fruit, spice, food,
standard-object, t}$\}$. The set $R$~$=$ $\{${\tt (pie, apple),
(apple, cinnamon), (apple, fruit), (cinnamon, spice), (fruit, food),
\hfil\break (spice, food), (food, standard-object), (standard-object,
t)}$\}$.
The class {\tt pie} is not preceded by anything, so it comes first;
the result so far is {\tt (pie)}. Remove {\tt pie} from $S$ and pairs
mentioning {\tt pie} from $R$ to get $S$~$=$ $\{${\tt apple, cinnamon,
fruit, spice, food, standard-object, t}$\}$ and $R$~$=$~$\{${\tt
(apple, cinnamon), (apple, fruit), (cinnamon, spice), (fruit,
food),\hfil\break (spice, food), (food, standard-object),
(standard-object, t)}$\}$.
The class {\tt apple} is not preceded by anything, so it is next; the
result is {\tt (pie apple)}. Removing {\tt apple} and the relevant
pairs results in $S$~$=$ $\{${\tt cinnamon, fruit, spice, food,
standard-object, t}$\}$ and $R$~$=$ $\{${\tt (cinnamon, spice),
(fruit, food), (spice, food), (food, standard-object),\hfil\break
(standard-object, t)}$\}$.
The classes {\tt cinnamon} and {\tt fruit} are not preceded by
anything, so the one with a direct {\word subclass} rightmost in the {\word
class
precedence list} computed so far goes next. The class {\tt apple} is a
direct {\word subclass} of {\tt fruit}, and the class {\tt pie} is a direct
{\word subclass} of {\tt cinnamon}. Because {\tt apple} appears to the right
of {\tt pie} in the {\word class precedence list},
{\tt fruit} goes next, and the
result so far is {\tt (pie apple fruit)}. $S$~$=$ $\{${\tt cinnamon,
spice, food, standard-object, t}$\}$; $R$~$=$ $\{${\tt (cinnamon,
spice), (spice, food),\hfil\break (food, standard-object),
(standard-object, t)}$\}$.
The class {\tt cinnamon} is next, giving the result so far as {\tt
(pie apple fruit cinnamon)}. At this point $S$~$=$ $\{${\tt spice,
food, standard-object, t}$\}$; $R$~$=$ $\{${\tt (spice, food), (food,
standard-object), (standard-object, t)}$\}$.
The classes {\tt spice}, {\tt food}, {\tt standard-object}, and {\tt
t} are added in that order, and the {\word class precedence list} is {\tt (pie
apple fruit cinnamon spice food standard-object t)}.
It is possible to write a set of {\word class} definitions that cannot be
ordered. For example:
\screen!
(defclass new-class (fruit apple) ())
(defclass apple (fruit) ())
\endscreen!
The class {\tt fruit} must precede {\tt apple} because the local
ordering of {\word superclasses} must be preserved. The class {\tt apple} must
precede {\tt fruit} because a {\word class} always precedes its own
{\word superclasses}. When this situation occurs, an error is signalled when
the system tries to compute the {\word class precedence list}.
The following might appear to be a conflicting set of definitions:
\screen!
(defclass pie (apple cinnamon) ())
(defclass pastry (cinnamon apple) ())
(defclass apple () ())
(defclass cinnamon () ())
\endscreen!
The {\word class precedence list} for {\tt pie} is {\tt (pie apple cinnamon
standard-object t)}.
The {\word class precedence list} for {\tt pastry} is {\tt (pastry cinnamon apple
standard-object t)}.
It is not a problem for {\tt apple} to precede {\tt cinnamon} in the
ordering of the {\word superclasses} of {\tt pie} but not in the ordering for
{\tt pastry}. However, it is not possible to build a new {\word class} that
has both {\tt pie} and {\tt pastry} as {\word superclasses}.
\endsubsubsection%{Examples}
\endsubSection%{Determining the Class Precedence List}
\beginsubSection{Redefining Classes}
A {\word class}
that is an {\word instance} of {\datatype standard-class} can be redefined
if the new {\word class}
will also be an {\word instance} of {\datatype standard-class}.
Redefining a {\word class} modifies the existing {\word class} object
to reflect the
new {\word class} definition; it does not create a new
{\word class} object for the
{\word class}. Any {\word method object}
created by a {\keyword :reader}, {\keyword :writer}, or
{\keyword :accessor} option specified by the old {\function defclass} form is
removed from the corresponding {\word generic function}.
{\word Methods} specified by the new {\function defclass} form are added.
% any function specified by the {\keyword :constructor}
% option of the old {\function defclass} form is removed from the
% corresponding symbol function cell.
When the class $C$ is redefined, changes are propagated to its {\word instances}
and to {\word instances} of any of its {\word subclasses}. Updating such an
{\word instance} occurs at an implementation-dependent time, but no later than
the next time a {\word slot}
of that {\word instance} is read or written. Updating an
{\word instance}
does not change its identity as defined by the {\function eq}
function. The updating process may change the {\word slots} of that
particular {\word instance},
but it does not create a new {\word instance}. Whether
updating an {\word instance} consumes storage is implementation-dependent.
Note that redefining a {\word class} may cause {\word slots}
to be added or deleted.
If a {\word class} is redefined in a way that changes the set of
{\word local slots}
accessible in {\word instances},
the {\word instances} will be updated. It is
implementation-dependent whether {\word instances} are updated if a
{\word class} is
redefined in a way that does not change the set of {\word local slots}
accessible in {\word instances}.
The value of a {\word slot}
that is specified as shared both in the old {\word class}
and in the new {\word class} is retained.
If such a {\word shared slot} was unbound
in the old {\word class}, it will be unbound in the new {\word class}.
{\word Slots} that
were local in the old {\word class} and that are shared in the new
{\word class} are
initialized. Newly added {\word shared slots} are initialized.
Each newly added {\word shared slot} is set to the result of evaluating the
captured {\keyword :initform} form for the {\word slot}
that was specified in the
{\function defclass} form for the new {\word class}.
If there is no {\keyword :initform}
form, the {\word slot} is unbound.
If a {\word class} is redefined in such a way that the set of {\word local
slots}
{\word accessible} in an {\word instance} of the {\word class}
is changed, a two-step process
of updating the {\word instances} of the {\word class} takes place.
The process may
be explicitly started by invoking the generic function {\function
make-instances-obsolete}. This two-step process can happen in other
circumstances in some implementations. For example, in some
implementations this two-step process will be triggered if the order
of {\word slots} in storage is changed.
The first step modifies the structure of the {\word instance} by adding new
{\word local slots} and discarding {\word local slots}
that are not defined in the new
version of the {\word class}.
The second step initializes the newly-added {\word local slots} and performs
any other user-defined actions. These two steps are further specified
in the next two sections.
\beginsubsubsection{Modifying the Structure of Instances}
The first step modifies the structure of {\word instances} of the redefined
{\word class} to conform to its new {\word class} definition.
Local {\word slots} specified
by the new {\word class} definition that are not specified as either local or
shared by the old {\word class} are added, and {\word slots}
not specified as either
local or shared by the new {\word class} definition that are specified as
local by the old {\word class} are discarded.
The {\word names} of these added and discarded
{\word slots} are passed as arguments
to {\function update-instance-for-redefined-class}
as described in the next section.
The values of {\word local slots} specified by both the new and old {\word
classes}
are retained. If such a local {\word slot} was unbound, it remains unbound.
The value of a {\word slot} that is specified as shared in the old
{\word class} and
as local in the new {\word class} is retained. If such a {\word shared slot}
was
unbound, the {\word local slot} will be unbound.
\endsubsubsection%{Modifying the Structure of the Instance}
\beginsubsubsection{Initializing Newly Added Local Slots}
The second step initializes the newly added {\word local slots} and performs
any other user-defined actions. This step is implemented by the generic
function {\function update-instance-for-redefined-class}, which is called after
completion of the first step of modifying the structure of the
{\word instance}.
The generic function {\function update-instance-for-redefined-class} takes
four required arguments: the {\word instance} being updated after it has
undergone the first step, a list of the names of {\word local slots} that were
added, a list of the names of {\word local slots} that were discarded, and a
property list containing the {\word slot} names and values of
{\word slots} that were
discarded and had values. Included among the discarded {\word slots} are
{\word slots} that were local in the old {\word class} and that are shared in the new
{\word class}.
The generic function {\function update-instance-for-redefined-class} also
takes any number of initialization arguments. When it is called by
the system to update an {\word instance} whose {\word class}
has been redefined, no
initialization arguments are provided.
There is a system-supplied primary {\word method} for {\function
update-instance-for-redefined-class} whose parameter specializer for
its {\word instance}
argument is the class {\datatype standard-object}. First this
{\word method} checks the validity of initialization arguments and signals an
error if an initialization argument is supplied that is not declared
as valid. (See the section ``Declaring the Validity of Initialization
Arguments'' for more information.) Then it calls the generic function
{\function shared-initialize} with the following arguments: the
{\word instance},
the list of {\word names} of
the newly added {\word slots}, and the initialization
arguments it received.
\endsubsubsection%{Initializing Newly added Local Slots}
\beginsubsubsection{Customizing Class Redefinition}
{\word Methods}
for {\function update-instance-for-redefined-class} may be defined
to specify actions to be taken when an {\word instance} is updated. If only
{\keyword :after} methods for
{\function update-instance-for-redefined-class} are
defined, they will be run after the system-supplied primary {\word method} for
initialization and therefore will not interfere with the default
behavior of {\function update-instance-for-redefined-class}. Because no
initialization arguments are passed to {\function
update-instance-for-redefined-class} when it is called by the system,
the {\keyword :initform} forms for {\word slots}
that are filled by {\keyword :before}
methods for {\function update-instance-for-redefined-class} will not be
evaluated by {\function shared-initialize}.
{\word Methods}
for {\function shared-initialize} may be defined to customize {\word class}
redefinition. See the section ``Shared-Initialize'' for more
information.
\endsubsubsection%{Customizing Class Redefinition}
\beginsubsubsection{Extensions}
There are two allowed extensions to {\word class} redefinition:
\beginlist
\itemitem{\bull} The \OS\ may be extended to permit the new {\word class}
to be an {\word instance} of a {\word metaclass}
other than the {\word metaclass} of the
old {\word class}.
\itemitem{\bull} The \OS\ may be extended to support an updating process
when either the old or the new {\word class} is an {\word instance} of a
{\word class}
other than {\datatype standard-class} that is not a {\datatype built-in-class}.
\endlist
\endsubsubsection%{Extensions}
\beginsubSection{Integrating Types and Classes}
The \CLOS\ maps the space of {\word classes} into the {\word type} space.
Every {\word class}
that has a proper name has a corresponding {\word type} with the same
{\word name}.
The proper name of every {\word class} is a valid type specifier. In
addition, every {\word class object} is a valid type specifier. Thus the
expression {\tt (typep {\tt object class\/})} evaluates to true if the
{\word class} of {\tt object\/} is {\tt class\/} itself or a
{\word subclass} of {\tt
class}. The evaluation of the expression {\tt (subtypep {\tt class1
class2\/})} returns the values {\tt t~t} if {\tt class1\/} is a
subclass of {\tt class2\/} or if they are the same {\word class}; otherwise it
returns the values {\tt nil~t}. If $I$ is an {\word instance} of some
{\word class}
$C$ named $S$ and $C$ is an {\word instance} of {\datatype standard-class}, the
evaluation of the expression {\tt (type-of $I$\/)} will return $S$ if
$S$ is the proper name of $C$\negthinspace; if $S$ is not the proper
name of $C$\negthinspace, the expression {\tt (type-of $I$\/)} will
return $C$\negthinspace.
Because the names of {\word classes}
and {\word class objects} are type specifiers, they may
be used in the special form {\function the} and in type declarations.
Many but not all of the predefined type specifiers have a
corresponding {\word class} with
the same proper name as the {\word type}. These type
specifiers are listed in Figure {\chapno--\the\capno}.
For example, the type {\datatype array\/}
has a corresponding {\word class} named {\datatype array\/}.
No type specifier that is a
list, such as {\tt (vector double-float 100)}, has a corresponding {\word
class}.
The form {\function deftype} does not create any {\word classes}.
Each {\word class} that corresponds to a predefined type specifier
can be implemented in one of three ways, at the discretion of each
implementation. It can be a {\datatype standard-class\/} (of the kind
defined by {\function defclass}), a {\datatype structure-class\/} (defined
by {\function defstruct}), or a {\datatype built-in-class\/} (implemented in
a special, non-extensible way).
A {\datatype built-in-class}
is one whose {\word instances} have restricted capabilities or
special representations. Attempting to use {\function defclass} to define
{\word subclasses} of a {\datatype built-in-class}
signals an error. Calling {\function
make-instance} to create an {\word instance} of a
{\datatype built-in-class} signals an error.
Calling {\function slot-value} on an
{\word instance} of a {\datatype built-in-class} signals an
error.
Redefining a {\datatype built-in-class}
or using {\function change-class} to change
the {\word class} of an {\word instance}
to or from a {\datatype built-in-class} signals an error.
However, {\datatype built-in-classes} can be used as parameter specializers in
{\word methods}.
%The \OS\ specifies that all predefined type specifiers
%listed in Figure~2-1 are built-in classes, but a particular
%implementation is allowed to extend the \OS\ to define some of them as
%standard classes or as structure classes.
It is possible to determine whether a {\word class}
is a {\datatype built-in-class} by
checking the {\word metaclass}.
A standard {\word class} is an {\word instance} of {\datatype
standard-class}, a built-in {\word class}
is an {\word instance} of {\datatype
built-in-class}, and a structure {\word class}
is an {\word instance} of {\datatype
structure-class}.
Each {\datatype structure} type created by {\function defstruct} without using the {\tt
:type} option has a corresponding {\word class}.
This {\word class} is an {\word instance} of
{\datatype structure-class}.
%A portable program must assume that {\datatype
%structure-class} is a subclass of {\datatype built-in-class} and has the
%same restrictions as built-in classes. Whether {\datatype structure-class}
%in fact is a subclass of {\datatype built-in-class} is
%implementation dependent.
The {\tt :include} option of {\function defstruct} creates a direct
{\word subclass} of the {\word class}
that corresponds to the included {\datatype structure}.
The purpose of specifying that many of the standard type
specifiers have a corresponding {\word class}
is to enable users to write {\word methods} that
discriminate on these {\word types}.
{\word Method} selection requires that a
{\word class precedence list} can be
determined for each {\word class}.
The hierarchical relationships among the type specifiers
are mirrored by relationships among the {\word classes} corresponding to those
{\word types}. The existing type hierarchy is used for determining the
{\word class precedence list}
for each {\word class} that corresponds to a predefined
{\word type}. In some cases,
a {\word local precedence order} is not specifiied for two {\word supertypes}
of a
given type specifier. For example, {\datatype null} is a {\word subtype}
of both
{\datatype symbol} and {\datatype list}, but it is not specified
whether {\datatype symbol} is more specific or less
specific than {\datatype list}. The \CLOS\ defines those
relationships for all such {\word classes}.
Figure {\chapno--\the\capno}
lists the set of {\word classes} required by the \OS\
that correspond to predefined type specifiers. The
{\word superclasses} of each such {\word class}
are presented in order from most
specific to most general, thereby defining the {\word class precedence list}
for the {\word class}. The {\word local precedence order} for
each {\word class} that
corresponds to a type specifier can be derived from this
table.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus .5 fil&&#\hfil\cr %was &&#
\noalign{\vskip -9pt}
\hfil\bf Predefined Type&\bf Class Precedence List for Corresponding Class\span\omit\span\omit\cr
\noalign{\vskip 2pt\hrule\vskip 2pt}
array&(array t)\cr
bit-vector&(bit-vector vector array sequence t)\cr
character&(character t)\cr
complex&(complex number t)\cr
cons&(cons list sequence t)\cr
float&(float number t)\cr
integer&(integer rational number t)\cr
list&(list sequence t)\cr
null&(null symbol list sequence t)\cr
number&(number t)\cr
ratio&(ratio rational number t)\cr
rational&(rational number t)\cr
sequence&(sequence t)\cr
string&(string vector array sequence t)\cr
symbol&(symbol t)\cr
t&(t)\cr
vector&(vector array sequence t)\cr
\noalign{\vskip -9pt}
}}
\caption{}
\endfig
Individual implementations may be extended to define other type
specifiers to have a corresponding {\word class}. Individual implementations
may be extended to add other {\word subclass} relationships and to add other
elements to the {\word class precedence lists} in the preceding figure,
as long as
they do not violate the type relationships and disjointness
requirements specified by this standard.
A standard {\word class} defined with no direct {\word superclasses} is guaranteed to
be disjoint from all of the {\word classes} in the table, except for the
class named {\datatype t}.
%The following Common Lisp types will have corresponding classes when
%Common Lisp is modified to define them each as being disjoint from {\datatype
%cons}, {\datatype symbol}, {\datatype array}, {\datatype number}, and
%{\datatype character}:
%
%\beginlist
%
%\item{\bull} function
%\item{\bull} hash-table
%\item{\bull} package
%\item{\bull} pathname
%\item{\bull} random-state
%\item{\bull} readtable
%\item{\bull} stream
%
%\endlist
\endsubSection%{Integrating Types and Classes}
∂21-Feb-89 2210 @Score.Stanford.EDU:linton@interviews.Stanford.EDU Re: Ph.D. program
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Feb 89 22:10:12 PST
Received: from interviews.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 21 Feb 89 22:06:59-PST
Received: by interviews.Stanford.EDU (5.57/Ultrix2.4-C)
id AA09458; Tue, 21 Feb 89 21:51:10 PST
Date: Tue, 21 Feb 89 21:51:10 PST
From: linton@interviews.Stanford.EDU (Mark Linton)
Message-Id: <8902220551.AA09458@interviews.Stanford.EDU>
To: goldberg@polya.stanford.edu
Subject: Re: Ph.D. program
Cc: faculty@score.Stanford.EDU
I recall a CSL discussion of similar issues when we were
forming the thesis proposal requirement. Students were
concerned about the "oral qual" you describe--it is very open-ended
when you can ask about research issues as well as general breadth.
The conclusion was that we (CSL) decided to make the systems breadth
requirement (qual) separate from a thesis proposal/research area exam.
There was also a lot of student anxiety about the notion of "failing"
the oral exam (now the thesis proposal).
It seems to be another disadvantage of this "oral qual" is that
the student's fate is in the hands of a smaller group (I assume
the exam committee would be small). I think this style of exam
would also require more faculty time. One of the reasons CSL switched
to a written qual was the feeling that oral exams were not the best
use of everyone's time. I would rather spend more time advising
students who are make reasonable-but-could-be-better progress
on their theses!
I applaud efforts to improve the system and I would certainly like
to help students complete their degrees more rapidly. However,
we should be very careful to introduce change only when we are sure
it will have a beneficial effect. I am unconvinced we have the evidence
necessary to convict the comps or quals of more than misdemeanors, and
I am even less sure of the effect of alternative proposals.
Mark
∂21-Feb-89 2237 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu NIPS POST-MEETING WORKSHOPS
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Feb 89 22:37:26 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA17757; Tue, 21 Feb 89 22:35:07 -0800
Message-Id: <8902220635.AA17757@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 21 Feb 89 22:35:34 PST
Received: by BYUADMIN (Mailer R2.01A) id 5531; Tue, 21 Feb 89 23:33:37 MST
Date: Tue, 21 Feb 89 08:42:23 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Stephen J Hanson <jose@TRACTATUS.BELLCORE.COM>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Stephen J Hanson <jose@TRACTATUS.BELLCORE.COM>
Subject: NIPS POST-MEETING WORKSHOPS
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
NIPS-89 POST-CONFERENCE WORKSHOPS
DECEMBER 1-2, 1989
REQUEST FOR PROPOSALS
Following the regular NIPS program, workshops on current topics in
Neural Information Processing will be held on December 1 and 2, 1989,
at a ski resort near Denver. Proposals by qualified individuals
interested in chairing one of these workshops are solicited.
Past topics have included: Rules and Connectionist Models; Speech,
Neural Networks and Hidden Markov Models; Imaging Techniques in
Neurobiology; Computational Complexity Issues; Fault Tolerance in
Neural Networks; Benchmarking and Comparing Neural Network
Applications; Architectural Issues; Fast Training Techniques.
The format of the workshops is informal. Beyond reporting on past
research, their goal is to provide a forum for scientists actively
working in the field to freely discuss current issues of concern and
interest. Sessions will meet in the morning and in the afternoon of
both days, with free time in between for ongoing individual exchange
or outdoor activities. Specific open and/or controversial issues are
encouraged and preferred as workshop topics. Individuals interested
in chairing a workshop must propose a topic of current interest and
must be willing to accept responsibility for their group's discussion.
Discussion leaders' responsibilities include: arrange brief informal
presentations by experts working on this topic, moderate or lead the
discussion; and report its high points, findings and conclusions to
the group during evening plenary sessions.
Submission Procedure: Interested parties should submit a short
proposal for a workshop of interest by May 30, 1989. Proposals should
include a title and a short description of what the workshop is to
address and accomplish. It should state why the topic is of interest
or controversial, why it should be discussed and what the targeted
group of participants is. In addition, please send a brief resume of
the prospective workshop chair, list of publications and evidence of
scholarship in the field of interest.
Mail submissions to:
Kathie Hibbard
NIPS89 Local Committee
Engineering Center
Campus Box 425
Boulder, CO, 80309-0425
Name, mailing address, phone number, and e-mail net address (if
applicable) should be on all submissions.
Workshop Organizing Committee:
Alex Waibel, Carnegie-Mellon, Workshop Chairman;
Howard Wachtel, University of Colorado, Workshop Local Arrangements;
Kathie Hibbard, University of Colorado, NIPS General Local
Arrangements;
PROPOSALS MUST BE RECEIVED BY MAY 30, 1989.
∂21-Feb-89 2239 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu WADS '89
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Feb 89 22:38:50 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA17798; Tue, 21 Feb 89 22:36:37 -0800
Message-Id: <8902220636.AA17798@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 21 Feb 89 22:37:04 PST
Received: by BYUADMIN (Mailer R2.01A) id 5591; Tue, 21 Feb 89 23:33:59 MST
Date: Tue, 21 Feb 89 08:47:58 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
DEHNE%CARLETON.CA@Forsythe.Stanford.EDU
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: DEHNE%CARLETON.CA@Forsythe.Stanford.EDU
Subject: WADS '89
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Please note that, because of a collision with PODC, the 1989 Workshop
on Algorithms and Data Structures has been shifted by one day to Aug. 17-19.
-----------------------------------------------------------------------
CALL FOR PAPERS
Workshop on Algorithms
and Data Structures
August 17-19, 1989
Carleton University
Ottawa, Canada
The Workshop, which continues the 1988 Scandinavian Workshop on
Algorithm Theory, is intended as a forum for researchers in the area of
design and analysis of algorithms and data structures.
We invite submissions of papers presenting original research on
algorithms and data structures in all areas, including combinatorics,
computational geometry, databases, graphics, parallel and distributed
computing. Contributors are invited to send 4 copies of a full paper
(not exceeding 12 pages) to
Workshop on Algorithms and Data Structures
School of Computer Science
Carleton University
Ottawa, Canada K1S 5B6
tel.: (613) 788-4333, 564-7545, e-mail: workshop@carleton.bitnet
Submissions must arrive before March 15, 1989. Authors will be notified
of acceptance or rejection by April 30, 1989. Proceedings will be
published, possibly in the Springer Verlag series Lecture Notes in
Computer Science. The final versions of accepted papers must arrive in
camera-ready form before May 25, 1989, to ensure the availability of the
proceedings at the conference.
Invited Speakers:
Michael Atallah (Purdue), Luc Devroye (McGill), Herbert Edelsbrunner
(Urbana Champaign), Gaston Gonnet (Waterloo), Jan van Leeuwen (Utrecht),
Chee Yap (Courant Institute).
Program Committee:
Selim Akl (Queen's), Frank Dehne (Carleton), Greg Fredrickson (Purdue),
David Kirkpatrick (UBC), Andrzej Lingas (Linkoeping), Kurt Mehlhorn (U.
des Saarlandes), Ian Munro (Waterloo), Joerg-Ruediger Sack (Carleton),
Nicola Santoro (Carleton), Esko Ukkonen (Helsinki), Jorge Urrutia
(Ottawa), Derick Wood (Waterloo).
Organizing Committee:
Frank Fiala, John Oommen, Ekow Otoo (Carleton), Robert Probert (Ottawa).
-----------------------------------------------------------------------
∂21-Feb-89 2241 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Seventh Amsterdam Colloquium -- Call for papers
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Feb 89 22:41:01 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA17876; Tue, 21 Feb 89 22:38:46 -0800
Message-Id: <8902220638.AA17876@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 21 Feb 89 22:39:13 PST
Received: by BYUADMIN (Mailer R2.01A) id 5674; Tue, 21 Feb 89 23:37:32 MST
Date: Tue, 21 Feb 89 09:09:00 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Leen Torenvliet <leen%uva.uucp%MCVAX.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Leen Torenvliet <leen%uva.uucp%MCVAX.BITNET@forsythe.stanford.edu>
Subject: Seventh Amsterdam Colloquium -- Call for papers
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Call for Papers
From December 19-22, 1989 the Seventh Amsterdam Colloquium will be held. The
Amsterdam Colloquia are organized every two years by the ITLI ('Instituut
voor Taal, Logica en Informatie') in which the Departments of Philosophy,
Mathematics and Computer Science of the University of Amsterdam cooperate
to stimulate and coordinate interdisciplinary research on language,
meaning and information. The Amsterdam Colloquia are devoted to the same
aim, and are open for all scholars working in this field, whatever their
background.
The Colloquium will consist of invited lectures and contributed talks.
People who want to contribute a paper are requested to send in an extended
abstract of approximately ten pages (4000 words) before September 1, 1989.
Abstracts postmarked later than August 31 cannot be accepted. All abstracts
will be strictly refereed by a program committee. Contributors will be notified
of acceptance by October 15. The abstracts of accepted papers will be
distributed among the participants in advance. Full proceedings will be
available shortly after the Colloquium is held.
Those who are interested in contributing a paper or in attending the
Colloquium, are kindly requested to return the accompanying reply form.
They will receive further announcements.
For further information contact:
Martin Stokhof
ITLI/Department of Philosophy
University of Amsterdam
Nieuwe Doelenstraat 15
1012 CP Amsterdam
The Netherlands
e-mail: stokhof%uvaalf.surfnet@hsara5.earn
or:
Leen Torenvliet
ITLI/Departments of Mathematics and Computer Science
University of Amsterdam
Nieuwe Achtergract 166
1018 WV Amsterdam
The Netherlands
e-mail: leen@uva.UUCP
-----------------------------------------------------------------------------
Reply Form
Seventh Amsterdam Colloquium, December 19-22, 1989
Name:
Address:
City:
Country:
| | wants to receive further announcements
| | intends to attend
| | intends to send in an abstract
-------------------------------------------------------------------------
∂21-Feb-89 2243 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Call for papers - FST&TCS9
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Feb 89 22:43:01 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA17951; Tue, 21 Feb 89 22:40:52 -0800
Message-Id: <8902220640.AA17951@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 21 Feb 89 22:41:19 PST
Received: by BYUADMIN (Mailer R2.01A) id 5747; Tue, 21 Feb 89 23:39:25 MST
Date: Tue, 21 Feb 89 09:16:32 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Ashok Chandra <ashok@IBM.COM>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Ashok Chandra <ashok@IBM.COM>
Subject: Call for papers - FST&TCS9
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Call For Papers - FST&TCS
Ninth Conference on
FOUNDATIONS OF SOFTWARE TECHNOLOGY AND THEORETICAL COMPUTER SCIENCE
Bangalore, India, 19-21 December 1989
FST&TCS conferences have been organized since 1981, to provide a forum for
presenting original research results, in Theoretical aspects of Computer
Science and Theoretical Foundations of Software Technology. Authors are
invited to submit papers in the following and related areas:
Theory of Computation
Automata and Formal Languages
Algorithms and Complexity
Formal Semantics, Specifications, and Proof Theory
Database Theory
Mathematical Aspects of Programming Languages
Functional and Logic Programming
Programming Methodology
Distributed Computing
Software Technology
Papers should be at most 20 PAGES (5000 WORDS) long. The covering letter
should indicate the address (and author, in case of multiple authors) for
all further correspondence. The names of the authors and their
affiliations should only appear on the cover page of the paper. It should
be possible to remove this page and send the papers to reviewers to
facilitate blind refereeing. Please also give the CR classification
numbers on the cover page. When citing papers submitted elsewhere, but
not published at the time of submission to this conference, the
similarities, and more importantly the differences between such works
must be clearly brought out. FOUR copies of each paper should
be sent to:
FST&TCS9 Conference Secretariat
TRDDC
1, Mangaldas Road
Pune 411 001, INDIA
Tel: (212)-662453 Telex: 0145-464
IMPORTANT DATES:
Last date for paper submission: May 15, 1989
Notification of acceptance to authors: August 1, 1989
Final camera-ready copy due on: September 5, 1989
CONFERENCE ADVISORY COMMITTEE:
D. Bjorner (Denmark)
A. Chandra (IBM Research)
S. Crespi Reghizzi (Milan)
Z. Galil (Columbia)
D. Gries (Cornell)
M. Joseph (Warwick)
A. Joshi (Pennsylvania)
U. Montanari (Pisa)
R. Narasimhan (TIFR)
M. Nivat (Paris)
R. Parikh (New York)
S. Rao Kosaraju (Johns Hopkins)
S. Sahni (Minnesota)
TECHNICAL PROGRAMME COMMITTEE:
G. P. Bhattacharjee (IIT Kharagpur)
S. Biswas (IIT Kanpur)
A. Kumar (IIT Delhi)
S. Kumar (TRDDC, Pune)
C. R. Muthukrishnan (IIT Madras)
K. V. Nori (TRDDC, Pune)
L. M. Patnaik (IISc, Banglore)
H. V. Sahasrabuddhe (Poona University)
R. Sangal (IIT Kanpur)
R. K. Shyamsunder (TIFR)
P. S. Thiagarajan (Matscience, Madras)
C. E. Veni Madhavan (IISc, Banglore)
G. Venkatesh (IIT Bombay)
∂21-Feb-89 2250 @Score.Stanford.EDU:gio@sumex-aim.stanford.edu Re: Ph.D. program
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Feb 89 22:50:47 PST
Received: from sumex-aim.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 21 Feb 89 22:48:09-PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA19274; Tue, 21 Feb 89 22:47:38 PST
Date: Tue, 21 Feb 1989 22:47:37 PST
From: Gio Wiederhold <gio@sumex-aim.stanford.edu>
To: Andrew V. Goldberg <goldberg@polya.stanford.edu>
Cc: faculty@score.stanford.edu
Subject: Re: Ph.D. program
In-Reply-To: Your message of Tue, 21 Feb 89 16:03:30 -0800
Message-Id: <CMM.0.88.604133257.gio@sumex-aim.stanford.edu>
Andy's proposal makes sense to me. Gio
∂21-Feb-89 2251 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Structure in Complexity Theory - Preliminary Program
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Feb 89 22:51:11 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA18159; Tue, 21 Feb 89 22:48:54 -0800
Message-Id: <8902220648.AA18159@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 21 Feb 89 22:49:21 PST
Received: by BYUADMIN (Mailer R2.01A) id 5874; Tue, 21 Feb 89 23:46:07 MST
Date: Tue, 21 Feb 89 09:36:21 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Stephen R. Mahaney" <srm@RESEARCH.ATT.COM>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Stephen R. Mahaney" <srm@RESEARCH.ATT.COM>
Subject: Structure in Complexity Theory - Preliminary Program
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Structure In Complexity Theory
Fourth Annual Conference
Sponsored by the
IEEE Computer Society Technical Committee on
Mathematical Foundations of Computing
and
The University of Oregon
In cooperation with ACM-SIGACT
June 18-22, 1989
University of Oregon Campus
Eugene, Oregon
PRELIMINARY TECHNICAL PROGRAM
(This Schedule is Subject to Changes)
Monday, June 19
Morning Session; Chair: Eric Allender
S. Kurtz, Chicago; S. Mahaney, AT&T Bell Laboratories; J. Royer, Chi-
cago; The isomorphism conjecture fails relative to a random oracle.
S. Homer, Boston Univ.; A. Selman, Northeastern; Oracles for struc-
tural properties: the isomorphism problem and public-key cryptography.
O. Watanabe, Tokyo Inst. Tech.; S. Tang, Beijin Comp. Inst.; On poly-
nomial time Turing and many-one completeness in PSpace.
J. Wang, Boston Univ.; P-creative sets versus p-completely creative
sets.
Afternoon Session; Chair: Jose Balcazar
S. Ben-David, B. Chor, O. Goldreich, Technion; M. Luby, Toronto;
Toward a theory of average case complexity.
J. Lutz, Iowa State; Almost everywhere high nonuniform complexity.
TO BE ARRANGED.
P. Clote, Boston College; E. Kranakis, Centre for Math & CS, Amster-
dam; Boolean functions, invariance groups, and parallel complexity.
Tuesday, June 20
Morning Session; Chair: Neil Immerman
R. Schore, Cornell; T. Slaman, Chicago; The P-T-degrees of the recur-
sive sets: lattice embeddings, extensions of embeddings, and the two
quantifier theory.
Y. Marcoux, Montreal; Composition is almost as good as s-1-1.
K. Regan, Cornell; Finitary substructure languages with application to
the theory of NP-completeness.
J. Trahan, LSU; V. Ramachandran and M. Loui, Illinois at Urbana-
Champaign; The Power of Parallel Random Access Machines with Augmented
Instruction Sets.
N. Immerman, Yale; S. Landau, Wesleyan; The complexity of iterated
multiplication.
Afternoon; OUTING or FREE TIME
Wednesday, July 21
Morning Session; Chair: Tim Long
E. Mayr, J. W. Goethe; A. Subramanian, Stanford; The complexity of
circuit value and network stability.
C. Wilson, Oregon; Decomposing NC and AC.
M. Krentel, Rice; On finding locally optimal solutions.
J. Cai, Yale; J. Hartmanis, Cornell; The complexity of the real line
is a fractal.
Afternoon Session; Chair: Janos Simon
T. Lam, Univ. Hong Kong; W. Ruzzo, Washington; Results on communica-
tion complexity classes.
U. Feige, A. Shamir; Weizmann Inst.; Multi-oracle interactive proto-
cols with space bounded verifiers.
M. Li, Harvard; P. Vitanyi, Amsterdam; Inductive reasoning and Kolmo-
gorov complexity.
E. Allender, Rutgers; The generalized Kolmogorov complexity of sets.
Thursday, June 22
Morning Session; Chair: Paul Vitanyi
R. Downey, Victorian Univ. of Wellington; W. Gasarch, U. Maryland; S.
Homer, Boston Univ.; M. Moses, Victorian Univ. of Wellington; On
honest polynomial reductions, relativizations, and P=NP.
Kobler, U. Stuttgart; U. Schoning, EWH Koblentz; S. Toda, Univ. of
Electro-communications, Tokyo; J. Toran, Barcelona; Turing machines
with few accepting computations and low sets for PP.
R. Beigel, Johns Hopkins; On the relativized power of additional
accepting paths.
R. Beigel, Johns Hopkins; L. Hemachandra, Rochester; G. Wechsung,
Friedrich-Schiller Univ.; On the power of probabilistic polynomial
time: P~NP[log] is contained in PP.
Afternoon Session; Chair: Avi Widgerson
L. Pitt, Illinois; M. Warmuth, UC-Santa Cruz; The minimum consistent
DFA problem cannot be approximated within any polynomial.
W. Maass, Illinois at Chicago; T. Slaman, Chicago; The complexity
types of computable sets.
M. Krause, Humboldt Univ.; C. Meinel, S. Waack, Akademie der Wissen-
schaften der DDR; Separating complexity classes related to certain
input oblivious logarithmic space-bounded Turing machines.
R. Chang, Cornell; On the structure of bounded queries to arbitrary NP
sets.
Jose Balcazar, Univ. Politecnica Catalunya; Nondeterministic witnesses
and nonuniform advice.
The Program Committee consisted of Eric Allender, Jose Balcazar,
Neil Immerman, Tim Long, Janos Simon, Paul Vitanyi, Avi Wigder
∂22-Feb-89 0023 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu CO89 Combinatorial Optimization Conference
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Feb 89 00:23:09 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA20679; Wed, 22 Feb 89 00:21:06 -0800
Message-Id: <8902220821.AA20679@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Wed, 22 Feb 89 00:21:33 PST
Received: by BYUADMIN (Mailer R2.01A) id 8485; Wed, 22 Feb 89 01:12:07 MST
Date: Tue, 21 Feb 89 10:23:08 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
M Dyer <dyer%DCS.LEEDS.AC.UK@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: M Dyer <dyer%DCS.LEEDS.AC.UK@Forsythe.Stanford.EDU>
Subject: CO89 Combinatorial Optimization Conference
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
CO89 Combinatorial Optimization Conference
10-13 July, 1989
University of Leeds, Leeds, U.K.
GENERAL INFORMATION
CO89 is the fifth in a series of conferences on Combinatorial Optimization which
have
been held at regular intervals in the U.K. The conferences are intended for up
to 100
participants to meet in a reasonably informal atmosphere.
TOPICS COVERED
All aspects of Combinatorial Optimization including:
Design and analysis of parallel and sequential algorithms.
Linear and integer programming.
Graph theory and combinatorics.
Complexity Theory.
Cryptography.
Applications in O.R. and Computer Science.
INVITED SPEAKERS
A. M. Frieze, Carnegie-Mellon University, Pittsburgh, U.S.A.
Z. Galil, Columbia University, New York, U.S.A. and Tel Aviv University, Israel.
M. R. Jerrum, Edinburgh University, U.K.
J. K. Lenstra, Centre for Mathematics and Computer Science, Amsterdam, and
Erasmus University,
Rotterdam, The Netherlands.
C. L. Monma, Bell Communications Research, U.S.A.
P. Toth, Bologna University, Italy.
CONFERENCE FORMAT
Each of the invited speakers will deliver a one hour lecture surveying results
in his area
of interest and presenting his own recent research.
Participants may contribute papers on any area of Combinatorial Optimization.
The time allowed
for these presentations will be 20-30 minutes. The deadline for abstracts will
be April 1, 1989.
Acceptance of the paper will be on the basis of this abstract, and contributors
will be notified
of acceptance within three weeks of submission.
It is expected that refereed papers from the conference will be published in a
special issue of
Discrete Applied Mathematics.
ARRANGEMENTS & COST
The conference will take place in Tetley Hall, which is a university hall of
residence
situated in its own pleasant grounds. All accommodation and meals will be
provided in the Hall.
It is hoped that participants will arrive in time for lunch on Monday, 10th
July.
Registration will take take place from 10 a.m. until 4 p.m. on Monday. The
conference
proceedings will begin at 2 p.m. on Monday and continue until 12.30 p.m. on
Thursday 13th.
(Lunch will be provided for participants on the 13th.) Overnight accommodation
(without meals)
can be booked for the nights of the 9th and/or 13th at a cost of 16.50 pounds
per night, in addition to
the conference fee.
The charge for accommodation and meals for the whole conference will be 102
pounds.
In addition there is a registration charge of 60 pounds to cover other costs.
It is hoped that it will be possible to refund some or all of the registration
fee
to participants if current applications for financial
support for the conference are successful. The total cost to participants is
therefore (currently)
162 pounds, if paid
before 31st May, 1989. There will be a late booking supplement of 10 pounds
thereafter.
Alternatively, participants may register on a daily basis at a cost of 35 pounds
per day including lunch, tea and coffee. Overnight accommodation including
dinner and breakfast
can be booked at a further cost of 35 pounds per night.
TRAVEL
There are direct flights from Amsterdam and Paris to Leeds and Bradford airport,
in addition to various internal flights. There are regular rail and coach
services
between Leeds and London.
LEEDS
The University of Leeds is one of the largest universities in the United
Kingdom.
Leeds itself is a lively modern city with a great variety of attractions and
cultural activities.
The city centre combines fine Victorian buildings with modern shopping
developments in mainly
pedestrian precincts. Leeds benefits from the open and varied countryside
immediately to the
North. The Yorkshire Dales National Park, containing some of the finest scenery
in Britain,
is within easy reach.
ORGANISING COMMITTEE
T. B. Boffey, Liverpool
M. E. Dyer (Secretary), Leeds
T. I. Fenner, London
S. French (Chairman), Leeds
R. W. Irving, Glasgow
C. J. H. McDiarmid, Oxford
C. N. Potts, Southampton
L. G. Proll (Treasurer), Leeds
R. Whitty, London
ENQUIRIES
Any enquiries and all correspondence about the conference should be addressed to
The Secretary, CO89
School of Computer Studies
University of Leeds
Leeds LS2 9JT
U.K.
e-mail: co89@uk.ac.leeds.dcs
CO89 APPLICATION FORM
Name: ..................................................................
Address: ..................................................................
..................................................................
..................................................................
..................................................................
..................................................................
Phone: ..................................................................
Please complete and return the appropriate section (A or B) below:
A : Full conference
Conference fee 162 pounds.
Number of extra nights (if any) at16.50 pounds per night: ...
(Indicate which nights in the space below.)
B : Daily attendance
Daily rate 35 pounds per day. Number of days: ...
(Indicate which days in the space below.)
Overnight accommodation, 35 pounds per night.
Number of nights: ...
(Indicate which nights in the space below.)
Please mail this form, and send payment (in pounds sterling) to the address
given for
enquiries above. Please note that there is a late booking supplement of 10
pounds for all
applications received after 31st May, 1989.
∂22-Feb-89 0030 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Capital City Conference on Combinatorics and Theoretical Computer
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Feb 89 00:29:47 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA20874; Wed, 22 Feb 89 00:27:43 -0800
Message-Id: <8902220827.AA20874@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Wed, 22 Feb 89 00:28:07 PST
Received: by BYUADMIN (Mailer R2.01A) id 8676; Wed, 22 Feb 89 01:21:27 MST
Date: Tue, 21 Feb 89 10:27:29 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
rodica simion <SIMION%GWUVM.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: rodica simion <SIMION%GWUVM.BITNET@forsythe.stanford.edu>
Subject: Capital City Conference on Combinatorics and Theoretical Computer
Scien
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
announcement *** call for papers *** registration information
CAPITAL CITY CONFERENCE ON
COMBINATORICS and THEORETICAL COMPUTER SCIENCE
MAY 22-26, 1989
at
The George Washington University, Washington, D.C.
sponsored by the National Science Foundation
and The George Washington University
The aim of the conference is to offer a setting for relaxed and
productive professional interaction between combinatorists and
theoretical computer scientists.
We will aim for substantive rather than numerous talks, in an effort to
maximize information content and depth, and to allow time for discussions
among the participants. We hope that the conference activities will
expand the participants' research interests across the
boundaries of the two disciplines, and lead to increased collaboration
between members of the two communities.
TOPICS AND PRINCIPAL SPEAKERS
graph theory: LASZLO LOVASZ
Princeton University and Eotvos Lorand University
"Communication Complexity of Graph Problems"
May 22, 11:00 a.m. and 2:00 p.m., and May 23, 11 a.m.
algebraic combinatorics:
RICHARD STANLEY
Massachusetts Institute of Technology
"Applications of Algebra to Combinatorics"
May 24, 11:00 a.m. and 2:00 p.m., and May 25, 11:00 a.m.
algorithms and complexity:
RICHARD KARP
University of California, Berkeley
"Randomized Algorithms"
May 25, 2:00 p.m. and May 26, 11:00 a.m. and 2:00 p.m.
Each principal speaker will give three lectures which will
overview the topic and will highlight major results, techniques, and open
problems. The principal speakers will be asked to provide a list of
suggested reading which will be made available to the interested
preregistrants before the time of the conference.
PROBLEM SESSION Thursday, May 25, 7:30 p.m.
We invite contributions of open problems which will
generate discussions and
collaborations. Please send problems, including references, by
March 1, 1989. Preregistered participants will receive the list of
problems before the beginning of the conference.
SPECIAL SESSION Wednesday, May 24, 7:30 p.m.
Interested participants are invited to an evening
discussion on topics
including funding sources for research in combinatorics and
theoretical computer science, and
educational issues in combinatorics and computer science. If you wish
to suggest other discussion topics, please do so by March 1, 1989.
CALL FOR PAPERS
We will schedule 25-minute contributed talks on subjects directly
related to the conference topics and consistent with the theme of
the conference. We will do our best to accommodate
contributed talks to the extent permitted by the intent to give sufficient
time to each talk, and to have time for informal discussions among
the participants.
If you are interested in giving a contributed talk, please submit
before March 1, 1989 a two-page abstract describing the subject, background,
and main results of your paper.
In the case of joint work, please indicate which of the authors will
give the talk.
A special issue of Discrete Applied Mathematics and/or Annals of
Discrete Mathematics will be devoted to the refereed proceedings
of this conference. Complete texts of submissions must reach
Rodica Simion by June 15, 1989.
PARTICIPANTS SUPPORT
Limited funds are available for partial support of participants,
in particular for graduate students.
Selection for the graduate student awards will be made based on a
description of the student's research interests and work, and two letters
of recommendation.
For full consideration, applications should be received by
March 7, 1989.
LOCAL INFORMATION
The conference talks will begin on May 22, at 9:00 a.m.,
in Marvin Center, room 402. The registration desk will open at 8:30 a.m.,
in room 410. Marvin Center is located on the GWU campus at 800↑ 21~{st}
Street, N.↑ W.
We have reserved blocks of rooms
at reduced rates, under "GWU Math Dept Conference",
at several hotels which are within 10-15 min.↑ walking distance of the
metro station and campus.
River Inn, 924↑ 25~{th} Street, N.W., (202) 337-7600;
↑$95 single/double.
Georgetown Marbury Hotel, 3000 M Street, N.W., (202) 726-5000;
↑$80 single/double.
State Plaza Hotel, 2117 E Street, N.W., (202) 861-8200 or
1-800-424-2859; mention "group number 2815";
↑$85 single, ↑$95 double.
Lombardy Hotel, 2019 I Street, N.W., (202) 828-2600;
↑$80 single, ↑$90 double.
Please call the hotel directly and guarantee your
reservations by April 21, 1989.
After this date, the rooms will be released, and the regular rates will
apply to available rooms.
On a first come first served basis, until April 15, 1989,
rooms can be reserved in
Thurston Hall, 1900 F Street, N.W.. This is a GWU DORMITORY
with air-conditioned rooms, private bath, and sheets/towels/etc. provided.
The information on the registration form is particularly important
in signing up for dormitory space. The rates are $30 for single, ↑$20 for
double occupancy.
From National Airport, take the metro Blue Line to the GWU/Foggy
Bottom stop, which is at 23~{rd} St. and I St., N.W. Cab rides from
National and Dulles Airports are approx. $10 and $30, resp. From
Union Station, take the metro Red Line to Metro Center, change to the Blue
Line, and get off at GWU/Foggy Bottom. Cab rides from Union Station are
approx. $5.
May weather in Washington is pleasant, with average highs of
68F and lows of 58F. May is also a popular camping time.
Attractive camping facilities exist at Greenbelt Park (National Park
Service), (301) 344-3948.
REGISTRATION
To register, please send your completed
registration form, or facsimile, and check to the address on the form.
Refunds, less ↑$10, will be made if a written request is received by
May 10, 1989.
REGISTRATION FORM
The following information will be very helpful in planning the
conference events.
Full name .................................................................
Title ...............................
Business address ...........................................................
...........................................................................
City .......................... State ...... Zip Code ............
Phone (B).........................Phone (H).........................
e-mail address .....................................................
Registration fee: $80 if received by April 15, 1989; $95 after April 15, 1989.
Amount enclosed ↑$ ...............
During the conference I will stay at Marbury ........ River Inn ........
Lombardy ......... State Plaza .......... Other ............................
Arrival time ........................ Departure time ........................
I wish to request a dormitory room.
I wish to share a room: yes .... no .... no preference ......
Sex F ........ M ........
My roommate should be smoker ...... non-smoker ....... no preference .......
For dormitory space, please send a separate check for the full
amount. Please make your check(s) payable to The George Washington
University, and mail your check(s) and registration form to Rodica Simion,
Department of Mathematics, George Washington University, Washington,
D.C. 20052.
MAIL and FURTHER INQUIRIES
Regarding the problem/special session, please contact
Louis Shapiro, Mathematics Department, Howard University, Washington,
D.C. 20059, (202) 636-7125; regarding other matters, please contact Rodica
Simion, Department of Mathematics, George Washington University, Washington,
D.C. 20052; (202) 994-6238; simion@gwuvm.bitnet
chairperson
Rodica Simion, George Washington University
program committee
Ira Gessel, Brandeis University
Robert W. Robinson, University of Georgia
Michael Saks, University of California, San Diego
organizing committee
Hosam Mahmoud, George Washington University
Louis Shapiro, Howard University
Dan Ullman, George Washington University
∂22-Feb-89 0052 @Score.Stanford.EDU:cheriton@Pescadero.Stanford.EDU Re: draft extra sentence to precede final paragraph
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Feb 89 00:52:08 PST
Received: from Pescadero.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 22 Feb 89 00:50:02-PST
Received: by Pescadero.Stanford.EDU (5.59/25-eef) id AA05887; Wed, 22 Feb 89 00:48:19 PDT
Date: Wed, 22 Feb 89 00:48:19 PDT
From: David Cheriton <cheriton@Pescadero.Stanford.EDU>
Message-Id: <8902220848.AA05887@Pescadero.Stanford.EDU>
To: JMC@SAIL.Stanford.EDU, faculty@Score.Stanford.EDU
Subject: Re: draft extra sentence to precede final paragraph
In-Reply-To: <E3asY@SAIL.Stanford.EDU> from John McCarthy
<JMC@SAIL.Stanford.EDU> on 21 Feb 89 1935 PST
I basically support JMC's position, but (living up the the general
reputation of academics) I find it rather fascinating the range of
problems raised by this sentence. In particular, how does one define
"offensive behavior" and "censorship"? If offensivity (word?) is in
the eye(?) of the beholder, presumably anything might be offensive
so censorship is not an appropriate tool for preventing or dealing
with any type of behavior? This society seems to have some "accepted" (?)
forms of censorship (such as true in advertising laws, laws against
advocating violence, making death threats, etc.)
I also wonder whether "censorship" has some clear delineations.
I wonder if the reality in this society is that this whoe issue is
actually a matter of judgment, not (just) a matter of principle.
∂22-Feb-89 0121 @Score.Stanford.EDU:cheriton@Pescadero.Stanford.EDU Random theories of PhD-ology
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Feb 89 01:21:00 PST
Received: from Pescadero.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 22 Feb 89 01:18:49-PST
Received: by Pescadero.Stanford.EDU (5.59/25-eef) id AA06100; Wed, 22 Feb 89 01:17:11 PDT
Date: Wed, 22 Feb 89 01:17:11 PDT
From: David Cheriton <cheriton@Pescadero.Stanford.EDU>
Message-Id: <8902220917.AA06100@Pescadero.Stanford.EDU>
To: faculty@score
Subject: Random theories of PhD-ology
1) Any trials and tribulations cause people to complain.
Students complain for the same reasons. Any changes to the system
will not signiifcantly decrease the complaints unless we cease to
fail people at all.
2) Our students suffer more from neglect than anything else. As child
psychologists will some day discover, children are better abused
than neglected. I think we'd all be better off if we demanded/expected
more from our students. Many of us can sing the praises of EE students
who survive the EE qual where only 1/3 or so make it each year.
3) Academics form committees because they are cowards.
The real purpose of the comp/qual committees to lean on students in ways
that we are too chicken to do individually (especially when it comes to
failing someone). Witness the number of fails on oral defenses!
Unfortunately, we have tricked ourselves into thinking this stuff
is actually an important part of a successful Ph.D. even though
it constitutes about 1/6 to 1/4 of the program and has no proven
correlation with the quality of the product - a new researcher.
I think it would be interesting for each faculty member to design the
optimal Ph.D. program for their students only(!) as an exercise for
the May retreat, and see how much commmonality we actually have.
David C.
∂22-Feb-89 1059 @Score.Stanford.EDU:hayes@arisia.xerox.com draft extra sentence to precede final paragraph
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Feb 89 10:59:37 PST
Received: from arisia.Xerox.COM by SCORE.STANFORD.EDU with TCP; Wed 22 Feb 89 10:56:21-PST
Received: by arisia.Xerox.COM
(5.59++/IDA-1.2.6) id AA29488; Wed, 22 Feb 89 10:53:48 PST
Date: Wed, 22 Feb 89 10:53:48 PST
From: Pat Hayes <hayes@arisia.xerox.com>
Message-Id: <8902221853.AA29488@arisia.Xerox.COM>
To: cheriton@Pescadero.Stanford.EDU
Cc: JMC@SAIL.STANFORD.EDU, faculty@SCORE.STANFORD.EDU
In-Reply-To: David Cheriton's message of Wed, 22 Feb 89 00:48:19 PDT <8902220848.AA05887@Pescadero.Stanford.EDU>
Subject: draft extra sentence to precede final paragraph
The ideas of 'giving offense' and 'censorship' are clearer, both
legally and in ordinary understanding, than David Cheriton implies.
Offensivity is not completely in the eye of the beholder: thus, for
example, incitement to commit a crime is not (merely) offensive, and
making false claims to mislead unwary consumers is not (merely)
offensive. Laws forbidding such behavior are not censorship laws in
the same sense that, say, laws forbidding the expression of religious
views, racial humor or pornographic anecdotes would be. The key
difference is that in the latter case, nobody will be harmed who cares
not to read the publications: one has the option of closing the book
if one finds it offensive.
Of course this is all a matter of judgement, and lines arent
completely sharp, and the issues are more complex than one likes to
think about. Nevertheless, surely a university should strive to draw
its boundaries on the side of freedom and openness; and closing down
an electronic bboard because it has a few jokes on it which might
offend scotsmen ( or jews, blacks, germans or poles ) seems
quite the wrong sort of action to take.
Pat
∂22-Feb-89 1110 @Score.Stanford.EDU:bhayes@polya.Stanford.EDU Proposed changes
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Feb 89 11:10:18 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 22 Feb 89 11:08:27-PST
Received: from LOCALHOST by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA05304; Wed, 22 Feb 89 11:06:51 -0800
Message-Id: <8902221906.AA05304@polya.Stanford.EDU>
To: faculty@score, phd-program@polya.Stanford.EDU
Reply-To: phd-program@polya.Stanford.EDU
Subject: Proposed changes
Date: Wed, 22 Feb 89 11:06:49 -0800
From: bhayes@polya.Stanford.EDU
I'm a bit worried that I keep hearing proposals for changes to the PhD
program, but I've heard very little discussion of the underlying
assumptions of these proposals. Rather than zero right in on changes,
why don't some of you discuss your opinions on:
o What is the purpose of the advisor/advisee relationship?
o What should a the world at large be able to infer about the holder
of a Stanford PhD?
o What are the skills every degree holder should have?
I have heard very little agreement on goal of the program, and until
there's some agreement on what the goals are, I don't see how we can
evaluate one suggestion against another.
-Barry
∂22-Feb-89 1127 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Textbook on Kolmogorov Complexity: in the making
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Feb 89 11:27:21 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA06151; Wed, 22 Feb 89 11:24:59 -0800
Message-Id: <8902221924.AA06151@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Wed, 22 Feb 89 11:25:23 PST
Received: by BYUADMIN (Mailer R2.01A) id 4182; Wed, 22 Feb 89 12:20:55 MST
Date: Wed, 22 Feb 89 09:11:08 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Paul Vitanyi <paulv%CWI.NL@Forsythe.Stanford.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Paul Vitanyi <paulv%CWI.NL@Forsythe.Stanford.EDU>
Subject: Textbook on Kolmogorov Complexity: in the making
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Textbook on Kolmogorov Complexity: in the making
For some time we have been engaged in a project to write a
book on ``Introduction to Kolmogorov Complexity and its
Applications,'' by Ming Li and Paul Vitanyi, to be published
by Addison-Wesley, 1990? We are aiming at a self-contained
text-book with many examples and exercises in both Kolmo-
gorov complexity (KC) and its applications. We strive for
comprehensive treatment of KC and all known applications of
KC, either to use in the main text or as examples or exer-
cises. Knowledge on the subject is scattered far and wide,
in different locations like East and West, and in different
disciplines like Statistics, Logics, Computer Science, Pro-
bability Theory, Philosophy, Mathematics. Therefore we ask
your help. If you know of any nice examples or exercises (no
matter how trivial or difficult) we would be grateful if you
could you send them to us.
We sollicit any help and suggestions you can give us on
subjects you feel are missing in the surveys below, more
detail on subjects that are mentioned, examples and exer-
cises, work that is not referenced or is missing. (A
separate comprehensive bibliography is available on
request.)
Unpublished material we use will be properly credited
in the main text of all versions. Lemmas, examples, exer-
cises and so on will be properly attributed.
Addresses (we prefer you to use the Netherlands
address): Ming Li, Computer Science Department, York Univer-
sity, 4700 Keeler Street, Ontario, Canada M3J 1P3
(li@yuyetti.bitnet); or Paul Vitanyi, CWI, Kruislaan 413,
1098 SJ Amsterdam, The Netherlands (paulv@piring.cwi.nl or
paulv@mcvax.bitnet).
Some pilot publications:
M. Li and P.M.B. Vitanyi, Two Decades of Applied Kolmogoro
Complexity, Proc. 3rd IEEE Structure in Complexity Theory
Conference, 1988, pp. 80-101. (Full expanded version to
appear as "Kolmogorov Complexity and its Applications" in
the `Handbook of Theoretical Computer Science' (Jan van
Leeuwen, Managing Editor), North-Holland. Preprint as CWI
report.)
M. Li and P.M.B. Vitanyi, Kolmogorovskaya slozhnost':
dvadsat' let spustia, Uspekhi Mat. Nauk, 43:6 (1988), pp.
129-166. (= Russian Mathematical Surveys)
∂22-Feb-89 1209 STAGER@Score.Stanford.EDU 1989/90 Courses and Degrees
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Feb 89 12:09:01 PST
Date: Wed 22 Feb 89 11:56:05-PST
From: Claire Stager <STAGER@Score.Stanford.EDU>
Subject: 1989/90 Courses and Degrees
To: faculty@Score.Stanford.EDU
Office: CS-TAC 29, 723-6094
Message-ID: <12472767115.19.STAGER@Score.Stanford.EDU>
A reminder:
All 1989/90 Courses and Degrees course description revisions must be turned
in to me by this FRIDAY, FEBRUARY 24.
Thanks.
Claire
-------
∂22-Feb-89 1327 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu CDOOD 89 - CFP
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Feb 89 13:27:44 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA14476; Wed, 22 Feb 89 13:25:28 -0800
Message-Id: <8902222125.AA14476@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Wed, 22 Feb 89 13:25:52 PST
Received: by BYUADMIN (Mailer R2.01A) id 6837; Wed, 22 Feb 89 14:22:00 MST
Date: Wed, 22 Feb 89 09:18:06 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Moshe Vardi <VARDI%ALMVMA.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Moshe Vardi <VARDI%ALMVMA.BITNET@forsythe.stanford.edu>
Subject: CDOOD 89 - CFP
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Call for Papers
The First International Conference
on Deductive and Object-Oriented Databases (DOOD89)
Kyoto, Japan December 4-6, 1989
Sponsored by: Advanced Software Technology & Mechatronics Research Institute
of Kyoto (ASTEM RI/Kyoto)
Information Processing Society of Japan (IPSJ)
Supported by: ECRC, ICOT, INRIA, MCC
in cooperation with: ACM SIGMOD, IEEE CS
Location: Conference Hall of the Science Center Bldg. in Kyoto Research Park
Aim:
Deductive databases and object-oriented databases are at the
forefront
of research in next generation intelligent database systems. Object-oriented
programming and design methodologies hold great promise in reducing the
complexity of very large software systems in such domains as computer-aided
design and manufacturing, integrated office information systems, and artificial
intelligence. Object-oriented database systems will enhance the programmer/user
productivity of such systems. Research in deductive databases is aimed at
discovering efficient schemes to uniformly represent assertions and deductive
rules, and to respond to highly expressive queries against the knowledge base
of assertions and rules, and to check for the validity of knowledge. As
for logic programming, logic has provided the basis for this area of research
and nowadays there are strong interactions between these two fields. Recently,
research has been aimed at integrating the object-oriented paradigm and
rule-based deduction to provide a single powerful framework for intelligent
database systems.
The primary objective of this conference is to provide a common forum of
technical discussions between researchers in deductive databases and
object-oriented databases, thereby accelerating the integration of the
technical outputs of these two areas of research. We expect the conference
to be continued on an annual basis with sponsorship from major next-generation
computer projects around the world, such as ECRC, ICOT, INRIA, and MCC.
Topics included:
The conference will address new developments in theoretical and practical
aspects of deductive databases (DD), object-oriented databases (OOD), and
the integration of these two disciplines. Papers are solicited which describe
original and novel research within this framework. The following is a partial
list of topics of interest.
Integrating Logic and Object Paradigms
Concurrent Logic/Object Programming
Integrity Enforcement in DOOD
Artificial Intelligence Techniques in DOOD
Query Languages and Query Optimization
Advanced User Interface to DOOD Systems
Operational DOOD Systems
Integration of DOOD with Programming Languages
Formalization of the Object-Oriented Concepts
Performance of DOOD Systems
Applications of DOOD Systems
Consistency Checking in DOOD
Instructions: Authors should submit five (5) copies of a full paper to one
of Program Committee Chairpersons by May 1, 1989. Papers should be no
longer than 20 typewritten (double spaced) pages in English. The Author
Name(s) and Affiliation(s) should appear on the cover sheet.
Program Committee Chairpersons:
[American]
Won KIM
MCC
3500 West Balcones Center Drive
Austin, Texas 78759
U.S.A.
Computer Mail: kim@mcc.com
[European]
Jean-Marie NICOLAS
ECRC
Arabellastr. 17
8000 Munich 81
FR Germany
Computer Mail: jmn@ecrcvax.uucp
[Far East]
Shojiro NISHIO
Dept. of Information and Computer Sciences
Faculty of Engineering Science
Osaka University
Toyonaka, Osaka, 560 Japan
Computer Mail: nishio%osaka-u.junet@RELAY.CS.NET
Important Dates:
May 1, 1989 Deadline for paper submission
August 1, 1989 Notification of acceptance
September 25, 1989 Final version due
November 1, 1989 Deadline for advanced registration
The Organization of Committees
General Chairperson: Yutaka Ohno (ASTEM RI/Kyoto)
Steering Committee Chairperson: Jack Minker (U. of Maryland)
Organizing Committee Vice-Chairperson: Yahiko Kambayashi (Kyushu U.)
Executive Committee Chairperson: Akifumi Makinouchi (Fujitsu)
Executive Committee Vice-Chairperson: Koichi Furukawa (ICOT)
Local Arrangement and Finance Chairperson: Kiyoshi Agusa (Kyoto U.)
Program Committee Members:
[American]
Hong-Tai Chou (MCC)
Umeshwar Dayal (CCA)
Dan Fishman (HP)
Yannis Ioannidis (U. of Wisconsin)
Roger King (U. of Colorado)
Frederik Lochovsky (U. of Toronto)
John Mylopoulos (U. of Toronto)
D. Stott Parker (UCLA)
Yehoshua Sagiv (Hebrew U.)
Oded Shmueli (Technion)
Satish Thatte (TI)
Allen Van Gelder (UC Santa Cruz)
Moshe Y. Vardi (IBM Almaden)
Carlo Zaniolo (MCC)
Stanley Zdonik (Brown U.)
[European]
Serge Abiteboul (INRIA)
Michel Adiba (U. of Grenoble)
Peter M. Apers (U. of Twente)
Malcom Atkinson (U. of Glasgow)
Francois Bancilhon (Altair)
Rudolf Bayer (TUM)
Catriel Beeri (Hebrew U.)
Stefano Ceri (Politecnico di Milano)
Robert Demolombe (ONERA-CERT)
Klaus R. Dittrich (U. of Karlsruhe)
Johann C. Freytag (ECRC)
Georges Gardarin (INRIA)
Alain Pirotte (Philips)
Joachim W. Schmidt (U. of Frankfurt)
Dionysios Tsichritzis (U. of Geneva)
Laurent Vieille (ECRC)
[Far East]
Hirofumi Katsuno (NTT)
Yoshifumi Masunaga (U. of LIS)
Takao Miura (Sanno I. of Business)
Nobuyoshi Miyazaki (Oki)
Setsuo Ohsuga (U. of Tokyo)
In-Sup Paik (DACOM of Korea)
Shixuan Sa (People's U. of China)
Ron Sacks-Davis (RMIT, Melbourne)
Katsumi Tanaka (Kobe U.)
Yuzuru Tanaka (Hokkaido U.)
Yoshihisa Udagawa (Mitsubishi)
Kazumasa Yokota (ICOT)
Masatoshi Yoshikawa (Kyoto Sangyo U.)
Requests for further information should be addressed to:
Prof. Kiyoshi AGUSA
c/o ASTEM RI/Kyoto
9F Asahi-Bldg., Oike Yanaginobanba
Nakagyo-ku, Kyoto, 604 Japan
Phone:+81-75-256-1677
Telex:5423115ENG KU J
Fax: +81-75-256-1670
(bitnet) agusa@jpnkyoto
(junet) agusa@astem.junet
or
[DOOD89 Secretary Address]
Ms. Ikuko MIYAZAKI
Manager, Marketing Division
Science Center International Corp.
17 Chudoji Minami-machi
Shimogyo-ku, Kyoto, 600 Japan
Phone:+81-75-322-7888
Fax: +81-75-322-5348
∂22-Feb-89 1336 X3J13-mailer recent sent to wrong mailing list
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 22 Feb 89 13:34:48 PST
Date: Wed, 22 Feb 89 10:04:32 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890222.100432.baggins@almvma>
Subject: recent sent to wrong mailing list
Sorry if this is a repeat for you. I'm resending the revised
document to this address as well.
=========================================================================
Date: Wed, 22 Feb 89 00:36:12 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <890222.003612.baggins@almvma>
Subject: cs proposal revisions
I've sent out a revised cs document for your review. It reflects
a number of your comments from the Hawaii meeting and over the
net. The larger changes were:
-- The 'depreciated' appendix is eliminated. I re-introduced
the list of implementation-dependent attribute support
items into the document proper. The other items in
appendix B were simply eliminated.
-- The functions sbchar and sgchar are eliminated. In general,
the comments indicate that case discrimination by schar
does not introduce a substantial performance penalty.
-- Character registry names and constituents are NOT defined by
Common LISP. The proposal defines only the framework for
composition and decomposition of characters. The naming
of registries and definition of their constituents are
left completely as an ISO standard activity.
-- Character registry names and constituents are NOT defined by
Common LISP. The proposal defines only the framework for
composition and decomposition of characters. The naming
of registries and definition of their constituents are
left completely as an ISO standard activity.
Please send comments to the X3J13 mailing list. If time allows
and it seems needed, I will send out another revision in time to
allow for an actual vote at the March meeting. A straw vote list
will follow shortly.
Regards,
Thom
=========================================================================
Date: Wed, 22 Feb 89 02:09:18 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <890222.020918.baggins@almvma>
Subject: Jan 1 cs proposal comments
>> From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
>> Subject: Comments on the Character proposal dated January 1, 1989
>>
>> Page 6 -- *all-registry-names* should be renamed to
>> *all-character-registry-names*; the word "registry" by itself
>> is too general.
I made this change to the latest version of the proposal.
>>
>> Page 9 -- the fourth bullet requires a defined total ordering of all
>> characters. This seems unnecessary, and is impossible to implement in any
>> system (such as Symbolics Genera) that allows dynamic addition of character
>> registries by third-party software vendors and by users; in such a system
>> character codes have to be allocated dynamically and therefore their order
>> cannot be fixed ahead of time.
You are quite right. This bullet is removed.
>>
>> Page 9 -- This says an implementation must define the result of
>> standard-char-p on the characters it supports. I think that is incorrect.
>> Common Lisp fully defines the result of standard-char-p, which is NIL
>> for all characters added by an implementation.
Right. This bullet is removed.
>>
>> Page 14 -- This EXTERNAL-WIDTH function probably should be part of a
>> database facility or a terminal screen template facility; I'm not sure it
>> is useful by itself. Also note that its result is only meaningful with
>> respect to a specific state of the stream. To give two examples, with the
>> SO/SI encoding the answer can vary by 1 depending on whether the stream is
>> already shifted into the correct state for the first character; with the
>> universal encoding Symbolics uses, the answer can vary by a lot depending on
>> whether the character repertoires appearing in the string have been used
>> earlier on the same stream (and hence have been assigned encoding numbers).
>> Because of this dependence on the state of the stream, I cannot think of
>> any correct use of EXTERNAL-WIDTH that does not involve immediately
>> outputting the string to the stream. Therefore I believe the same effect
>> can be achieved without adding any new functions, by calling FILE-POSITION,
>> outputting to the stream, calling FILE-POSITION again, and subtracting. If
>> you still want to propose this feature, you should change the name: use
>> "length" instead of "width", since that's the word Common Lisp always uses,
>> and use a name that relates to the :EXTERNAL-CODE-FORMAT option to OPEN;
>> for example, STRING-LENGTH-IN-EXTERNAL-CODE-FORMAT or
>> EXTERNAL-CODED-STRING-LENGTH.
I changed the name to EXTERNAL-CODED-STRING-LENGTH. The description
already contained a comment regarding current state. Actually, I
favored the STREAM-INFO proposal which was voted down. This is
much less ambitious but I still feel more useful than actually
forcing I/O, backing up and rewriting. It's also not clear
that your alternative has the same effect since it seems that
some unwanted side-effects would occur such as premature appearance
on a display screen.
>>
>> Page 24 -- I can't figure out what you intend the meaning of SIMPLE-STRING
>> to be. Your report mostly does not mention it, but it doesn't say to
>> remove it either. If I have correctly correlated page 24 back to CLtL, you
>> are defining SIMPLE-STRING to be synonymous with SIMPLE-GENERAL-STRING.
>> Maybe what you really meant, though, was what you said in November you
>> would do, which was to make SIMPLE-STRING mean (AND STRING SIMPLE-ARRAY),
>> in other words a union of several subtypes. This is particular confusing
>> because Common Lisp uses the name SIMPLE-VECTOR to mean what you might call
>> a simple general vector, that is, (SIMPLE-ARRAY T 1) rather than
>> (SIMPLE-ARRAY * 1). Here are my suggestions for what to do with the
>> various names for string subtypes:
>>
>> STRING As a union of all strings, this is fine.
>> GENERAL-STRING I think (VECTOR CHARACTER) is just as good.
>> BASE-STRING I think (VECTOR BASE-CHARACTER) is just as good.
>> SIMPLE-STRING Should mean (SIMPLE-ARRAY CHARACTER 1).
>> SIMPLE-BASE-STRING This is fine.
>> SIMPLE-GENERAL-STRING This name is horrible, use SIMPLE-STRING.
>>
>> My rationale for these suggestions largely comes from thinking about
>> which of these names would ever be used in type declarations and about
>> how these names relate to the other names already in Common Lisp. To
>> repeat older comments:
>>
>> Pages 19 and 20 introduce a new type named simple-base-string, in addition
>> to simple-string. If you think about how simple-string would be used for
>> compiler optimization, it makes sense for simple-string to be the name for
>> the single simplest representation, rather than a name for a whole family
>> of representations that would have to be discriminated at run time. Thus
>> what you call simple-base-string should be called simple-string, and what
>> you call simple-string should just be called (simple-array character (*)).
>> This would not be an incompatible change in the meaning of simple-string.
>> Simple-string would be analogous to simple-vector.
>>
>> I changed my mind slightly on that and now claim that while SIMPLE-STRING
>> should still be a single representation, not a union, it should be the
>> representation that can hold all characters. This is both because of the
>> principle that correct programs should be easier to write than
>> extra-efficient programs, and because of the powerful analogy with the name
>> SIMPLE-VECTOR. Then the name SIMPLE-BASE-STRING is also needed for
>> convenient type declarations of the more efficient but less functional
>> string representation. That name is good, by analogy to BASE-CHARACTER.
>>
>> Adopting the above suggestions helps you decide what to do about the
>> SCHAR, SBCHAR, and SGCHAR mess. First of all, you only need two functions,
>> not three, because there are only two specified specialized representations.
>> SCHAR should be for what I've called SIMPLE-STRING, SBCHAR should be
>> for SIMPLE-BASE-STRING, and SGCHAR is not needed. (In fact I would prefer
>> to remove all of the specialized versions of AREF from the language, in
>> favor of THE or type declarations, but I know that would only pass over
>> some peoples' dead bodies so I won't push it.)
>>
>> In case you are wondering, I have no quarrel with the name BASE-CHARACTER
>> and would not want to see it removed. I guess I differ from Larry here,
>> unless I erred when I wrote down his comments during the meeting.
The statement on p24 making SIMPLE-STRING == (SIMPLE-ARRAY CHARACTER (*))
was in error. P25 had it right. Since we changed SCHAR to accept
all simple strings there is no reason for SGCHAR and SBCHAR and
these are eliminated.
String and simple-string are (more clearly I hope) defined as union
types. I've changed the terminology from 'for the purpose of
declaration' to 'for object creation'. Perhaps there is a better
term but the effect seems to be identical to what you suggest. That is,
correct, portable programs are easier to write, one simply uses
string and simple-string. More efficient, less portable programs
need to specify the specialized subtype(s) explicitly.
Having both string and simple-string defined as union types seems
desirable on the basis of uniformity.
Of the type abbreviations I think BASE-CHARACTER is the most
useful and GENERAL-STRING, SIMPLE-BASE-STRING and SIMPLE-GENERAL-STRING
less so. I don't believe that any of these really complicate the
language.
>>
>> Page 25 -- The discussion of STRING and SIMPLE-STRING thinks that there
>> is a distinction between declaration and discrimination, but Common Lisp
>> no longer has such a distinction. Even when Common Lisp did have such
>> a distinction, the meanings for declaration stated here were incorrect.
I changed this to 'object creation'. Perhaps there is a better term.
>>
>> Page 29 -- *all-character-registry-names* has to be a variable, not a
>> constant, to accomodate systems (such as Symbolics Genera) that allows
>> dynamic addition of character registries by third-party software vendors
>> and by users.
Right, I made this change.
>>
>> Page 35 -- CHAR-REGISTRY should be renamed to CHAR-REGISTRY-NAME, so that
>> if at some later time character registry objects are added, there is no
>> possibility of confusion about whether this function returns a name or
>> an object.
Right, I made this change.
>>
>> Page 40 -- the default :ELEMENT-TYPE for OPEN cannot be BASE-CHARACTER. I
>> think this was discussed at the X3J13 meeting. The report suffers from a
>> confusion between two meanings of BASE-CHARACTER: the character type
>> implemented most efficiently by the Lisp, and the character type most
>> natural to the file system. These are not always the same. Furthermore,
>> in a network-based system that supports multiple file systems equally
>> (Symbolics Genera is an example), each file system might have a different
>> natural character type. BASE-CHARACTER should just mean the character type
>> implemented most efficiently by the Lisp. The default for :ELEMENT-TYPE
>> has two viable choices that I can see, and maybe you should just propose
>> both and let people vote:
>>
>> (1) CHARACTER. This matches the behavior of MAKE-STRING and friends,
>> adheres to the principle that writing correct programs should be easier
>> than writing extra-efficient programs (since making a program correct
>> requires making every part of it correct, while making a program
>> efficient only requires improving the bottlenecks), and doesn't cost
>> anything in implementations that don't have extended characters.
>>
>> (2) The most natural type for the particular pathname being opened.
>> In some systems this would be a constant, and in a subset of those
>> systems this would be BASE-CHARACTER, however in general this might
>> depend on the host, device, or even type fields of the pathname,
>> and might also depend on information stored in the file system.
>> In general this would always be an (improper) supertype of
>> BASE-CHARACTER, but it's probably a bad idea to make that a requirement,
>> as some file systems might not be able to implement it conveniently.
>> Again this doesn't cost anything in implementations that don't have
>> extended characters.
The discussion on p16 about the base coded character set efficiency
has been removed. The default element-type now states that it is
implementation defined as character or a subtype of character.
>>
>> The relationship of option 2 to :ELEMENT-TYPE :DEFAULT (a feature that
>> already exists in Common Lisp) needs to be clarified. Perhaps they
>> are the same.
The same? I don't understand. For example, I can imagine the
element-type default as base-character and the external format
defaulted to either an ASCII or EBCDIC encoding.
>>
>> Also the following promise from 14 November did not show up in the report:
>>
>> >> There should be a name for the "natural" encoding and there should be a
>> >> specification of the properties of the natural encoding that a programmer
>> >> can rely on. Suggestions for the name include :BASE, :NATURAL, and
>> >> :INTERCHANGE. The definition probably involves the concept of data
>> >> interchange with non-Lisp programs on the same system.
>>
>> This will be added to the revision.
I lied. No one came up with the 'properties' of such an encoding.
Do you have some text to suggest?
>>
>> Appendix B -- I disagree with the way you've used deprecation. I'll
>> comment on each individual point:
>> - I see no justification for deprecating STANDARD-CHAR.
>> - I agree that STRING-CHAR should be deprecated, not deleted nor kept.
>> - I think fonts and bits should be removed outright, not deprecated,
>> because no portable program could possibly be using them.
>> - I think the CHAR-INT function needs to be kept, although the INT-CHAR
>> function should go away. This is for hashing. See comments below
>> on character attributes.
I've removed Appendix B and mention of deprecation. STANDARD-CHAR
is simply (characterp :standard). String-char is back in as
implementation-defined either character or base-character (and
maybe should be voted as a deprecated type).
>>
>> No particular page -- the use of strings for naming registries, labelling
>> characters, and naming external code formats is objectionable. Nothing
>> else in Common Lisp is named by strings. Use of strings might lead to
>> efficiency problems. We feel that keyword symbols are the appropriate
>> objects to use for these three kinds of names.
I changed these back to symbols.
>>
>> No particular page -- We agree with the deprecation or deletion of the two
>> particular character attributes defined by CLtL, but not with the
>> deprecation of the whole concept of character attributes. In fact on page
>> 20 you say "characters are uniquely distinguished by their codes," which
>> makes it impossible to have character attributes at all. The language must
>> define how conforming programs should be written so that they will work
>> both in implementations with character attributes and in implementations
>> without them. For example, the value of (eql x (code-char (char-code x)))
>> is unspecified. Another thing that needs to be said is that the exact
>> character operations (char=, string=, etc.) respect all character
>> attributes, while the inexact character operations (char-equal,
>> string-equal, etc.) respect or ignore each character attribute in an
>> implementation-defined but consistent fashion. Some of what you say on
>> page 44 about attributes in general needs to be part of the spec, not
>> deprecated. I would retain everything on that page except for INT-CHAR and
>> the last bullet (referring to bits and fonts), and I would add a remark
>> that FIND-SYMBOL and INTERN respect character attributes. If you want,
>> perhaps I or someone else at Symbolics can provide exact text for what
>> to say about character attributes that you could insert into your report.
I moved the attribute list previously in Appendix B back into the
description of characters. Let me know what text you would like
to see for FIND-SYMBOL and INTERN and I'll add it to the list.
>> No particular page -- On the subject of defining character registries in a
>> separate document, and relating them to ISO standards for character
>> encoding: I think that's fine. I don't see anything wrong with introducing
>> the concept of character registry and the requirement that each character
>> object relates to exactly one registry. However, I think the somewhat
>> random list of character registries on pages 7-8 and again on page 21 does
>> not belong in the language specification. Even the names of the
Right. They are not part of the Common LISP standard. The revised
document is considerably clearer in this regards.
>> standardized character registries belong in the character registry
>> standard, not in the Common Lisp language standard. I'm confused about the
>> meaning of BASE, STANDARD, and CONTROL as character registry names; these
>> are mentioned in your report but not explained very well. If these are
>> character registries that are required to exist in all Common Lisp
>> implementations, then unlike the others they do belong in the Common Lisp
>> language standard, not in the character registry standard.
By CONTROL, I meant a registry which contains the various control
codes mentioned in the various ISO coded character set standards.
BASE and STANDARD are no longer mentioned here. They are allowed
as Common LISP repertiore names in characterp and the character
type specifier.
>>
>> At the meeting there was some discussion about the issue of enumerating all
>> characters in a character registry. People claimed incorrectly that it was
>> impossible. In fact it's possible to do this, with questionable
>> efficiency, by the following program:
>>
>> (dotimes (code char-code-limit)
>> (let ((char (code-char code)))
>> (when char
>> (when (eq (char-registry-name char) desired-registry-name)
>> ... process this char ...))))
>>
>> Of course you have to change the EQ to EQUALP if you continue to use
>> strings to name character registries. For more efficiency, you could add
>> a way to iterate over all the codes in one character registry, but I think
>> that is unnecessary.
>>
>>
>> TYPOS:
Right. I've made these corrections.
>>
>> 25 -- base-string is missing from the Table 4-1 amendment.
>>
>> 26 -- general-string is not an array of BASE characters, also the first
>> two paragraphs under A.4.8 are garbled (the two separate sentences for
>> strings for symbols got smushed together).
>>
>> 37 -- This says the default for the :ELEMENT-TYPE option to MAKE-STRING
>> is SIMPLE-STRING. Actually it's CHARACTER.
>>
=========================================================================
Date: Wed, 22 Feb 89 03:48:56 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <890222.034856.baggins@almvma>
Subject: cs proposal comments
>> From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
>> Subject: comments on character proposal
>>
>> Getting rid of bits and fonts (section 2.1) seems like a very good
>> idea to me. I would argue for deleting these "features" completely
>> instead of merely deprecating them, because there now seems to be
>> general agreement that the whole idea was brain-damaged in the first
>> place, plus it's just about impossible to use them portably anyway
>> (since implementations are free not to support them). Deprecating the
>> features would simply perpetuate the current sad state of affairs in
>> to the ANSI standard.
I deleted Appendix B from the proposal. The attribute check list is
incorporated into the character chapter as implementation dependent.
>>
>> I am not at all sure why we need to standardize the idea of character
>> registries at all, much less state that a character can only belong to
>> one registry, or define a standard set of registries. What does having
>> registries buy the user, other than perhaps a way to test whether a
>> character belongs to one or not? Why isn't it sufficient just to say
>> that implementations can support extended characters, and leave it at
>> that?
The registries are introduced to allow an application a portable
way to name, compose and decompose characters. Currently, there is
no way to do this in any programming language. There are other
possiblities. For example, simply labeling all characters
uniquely; another to define a universal coded character set and use
these numeric codes to 'name' characters. I don't think using
numbers for naming characters is useful since I'll always forget
what character 34539 actually is! Registries seem to provide a
framework for useful categorization of characters. It also
avoids the current mess that the coded character set standards
are in.
>>
>> I'm confused about how you propose to handle characters that appear in
>> more than one character repetoire, and whether characters with accent
>> marks are considered distinct from characters without accents. For
>> example, is the French "C" with a cedilla distinct from a normal
>> French "C", and is that distinct from the standard-char "C"?
We handle characters that appear in more than one repertoire by
using registries. No character appears in more than one registry.
The constituents of the registries are not defined by Common LISP.
I believe that in most environments today, it is recognized that
characters with accents are distinct from their vanilla cousins.
As we have proposed registries, they contain semantically
distinct characters.
>>
>> The way the document describes things now, it seems like the Common
>> Lisp standard would have to include a statement of exactly what
>> characters belong in each of the standard registries listed in section
>> 2.2. Otherwise, implementors might go off and define their own
>> character registries that happen to include some characters that ought
>> to belong in one of these standard registries. For instance, the machine
>> I happen to be sitting in front of right now supports an 8-bit native
>> character set, and it seems perfectly reasonable for a Lisp runnning on
>> this machine to include all 256 characters in its base character set,
>> but some of those might actually be supposed to live off in some other
>> registry.
The registries are independent of any coded character sets.
In particular, coded character sets are not registries. Your base
repertoire (set of 256 characters) are possibly drawn from
several registries.
You are correct that lacking an international standard (or ANSI one),
for character registries an implementation could define the
a single registry containing all supported characters. It could
also define NO registries and use only the conventional naming
of characters. I expect an implementation taking the no-cost way
would choose the second approach. On the other hand, an
implementation supporting text processing across international
boundaries is more likely to define some reasonable registries
eg. Latin, Greek, etc..
>>
>> Also in section 2.2, why is it necessary for there to be a total
>> ordering, or even a partial ordering, of all characters? It seems
>> like CHAR< and friends are not very useful except when comparing base
>> characters anyway. It seems like it would difficult to get things
>> like the Spanish N-with-twiddle character to collate correctly anyway,
>> given the constraints you have put on how character codes are derived
>> and the requirement that CHAR< be just like < on the char-codes.
Right. This is now removed.
>>
>> It doesn't seem like STANDARD-CHAR-P belongs in the list of character
>> predicates on p. 9, since no extended characters can possibly be
>> STANDARD-CHAR-P anyway.
Right. This is now removed.
>>
>> The stuff in section 2.3 seems mostly reasonable to me. It's not really
>> clear why you need GENERAL-STRING (as distinct from STRING) and
>> SIMPLE-GENERAL-STRING (as distinct from SIMPLE-STRING). Again, some
>> rationale would be helpful.
GENERAL-STRING means (VECTOR CHARACTER). This is not the meaning of
STRING (a union type). I agree that GENERAL-STRING is not much
of an abbreviation over (VECTOR CHARACTER). It still seems somewhat
more mnemonic.
>>
>> In section 2.4, the general idea of specifying an external character
>> encoding to OPEN seems reasonable. However, I'm confused by the
>> business about having more than one coded character set mixed
>> together. If a character appears in more than one coded character
>> set, which encoding takes precedence? It seems like this has not been
>> well thought-out. Also, seeing as though we have just voted down a
>> proposal to add an EXTERNAL-WIDTH function, it seems like a very bad
>> idea to lump it in here.
Some encoding schemes allow disjoint coded characters sets to
coexist. That is, a given character would appear on one but not
the other. For example, a ISO8859/1 coded character set could
coexist with a coded character set for Chinese.
As for External-width, it was part of our subcommittee discussions
long before the recent stream proposal. It will be a separate
item in the list of character votes.
>>
>> Now for the general comments.
>>
>> One thing that is not clear to me from reading this document is how
>> much of it has already been standardized by ISO. I share Larry's
>> concern that we might standardize one thing, and then have ISO go off
>> and standardize something completely different. I think it's a
>> mistake to try to second-guess what ISO might do.
The revision might make this clearer. I think this is a
red herring anyhow. As a programming language committee
we need to specify what is useful in the context of LISP. We
can't expect a coded character set committee to figure it out.
On the other hand, we can influence what gets standardized
by defining our framework. The ISO Prolog std committee is
interested in what we define.
>>
>> I am also concerned about trying standardize things that have not yet
>> been implemented. I think it's a mistake to try to do language design
>> in a standards committee.
>>
>> Finally, I have some problems with the presentation of your proposal.
>> One problem, as I mentioned at the meeting, is that you've made it an
>> all-or-nothing package, and I can't vote for the whole thing because
>> there are some parts of it that do not seem appropriate, even though I
>> would support some of the other changes individually. The other
>> problem is that Appendix A is virtually unreadable. Some of the
>> conceptual changes involve wording changes to several passages, and I
>> know that there are some other changes in the appendix that are not
>> mentioned in the introductory blurb at all. Is it totally impossible
>> to recast the changes in standard cleanup format proposals? The
>> advantage of that format is that it presents more context, including a
>> clear statement of why the existing CLtL behavior is "broken" and a
>> rationale for the proposed change.
There will be several votes regarding this proposal. I don't
intend to rewrite the document in a cleanup format.
>>
>> I know that we adopted things like the CLOS document that were
>> presented as single mega-proposals, but those were primarily additions
>> to the language and what you are proposing is essentially a large
>> number of incompatible changes. I'm having a hard time identifying
>> what all of those changes are.
>>
Actually, I don't think it's as large a number of changes as you
imply. In any case, the vote split should help this out.
=========================================================================
Date: Wed, 22 Feb 89 04:51:15 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
cc: David Gray <GRAY%DSG.CSC.TI.COM@RELAY.CS.NET>
Message-ID: <890222.045115.baggins@almvma>
Subject: cs proposal comments
>> From: David N Gray <Gray@DSG.csc.ti.com>
>> Subject: characters proposal
>>
>> I have read the documented titled "Extensions to Common LISP to Support
>> International Character Sets" dated January 1, 1989, and feel that it is
>> not much of an improvement over what we saw in October. Following are
>> some random comments about things I happened to notice; this is not
>> intended to be a comprehensive analysis.
>>
>> First, documents such as this ought to be labelled with an X3J13
>> document number so that they can be referred to conveniently and
>> unambiguously.
>>
>> "Appendix A" and "Appendix B" really should be chapters 3 and 4 since
>> they are an essential part of the proposal, rather than being an
>> appendage to it.
Appendix B is now eliminated. Appendix A is really quite unlike
chapters 1 and 2 in structure.
>>
>> Page 7 says that the definition of semi-standard-characters "is replaced
>> by a more uniform approach with introduction of the Control Character
>> Registry". Do you really mean that it _will_be_ replaced when the
>> Control Character Registry is defined in some subsequent document? I
>> certainly don't see anything in this document that could be considered a
>> replacement.
Yes. The revision is clearer on this. This document does not define
names for character registries nor their constituents.
>>
>> This whole concept of registries seems rather strange. Is the intent
>> that the alphabetic characters of the standard characters are to be in
>> the "Latin" registry while characters such as period and comma are in
>> "Latin-Punctuation"? Is #\NEWLINE in the "Control" registry? Where do
>> the digits go -- "Mathematical"?. Is #\- a "Latin-Punctuation" or a
>> "Mathematical"? Which registry is #\SPACE in? Now tell me what to do
>> with the extra non-Latin alphabetic characters used in Sweedish? Does
>> that require a separate registry for just those additional characters?
>> Now we have simple text in a single language using characters from at
>> least four different registries. Do you really think it possible to
>> agree on a "fixed", non-extensible, set of "Mathematical" or "Pattern"
>> characters?
Actually, I believe the simplicity of the registry framework will make
agreement easy. Currently, members of the coded character set
committees spend vast amounts of time lobbying for inclusion of their
favorite character(s) in the 'popular' coded character set standard.
The effect of not being included means fewer installations will
support their native language properly.
I think a new group, hopefully formed within
programming languages, should define the registries rather than
the existing coded character set committees. There is no competition
between registries, ie. no advantage of one over another. What this
committee has to agree upon is 1) a useful set of registry names and
2) definition of the constituents of each registry. The only argument
I would anticipate is "are the semantics of my alpha the same
or different from your alpha" type debates.
By the way,
the registries are fixed only in that a Common LISP implementation
cannot modify the standard definitions. This guarantees an application
program can portably rely on the composition and decomposition
functions to establish the availability of any given character.
>>
>> Page 9 says that an implementation needs to specify the total ordering
>> of characters within each registry, but what about the ordering of
>> characters in different registries? Is that completely undefined?
There is no ordering of characters within registries. As mentioned
in Hawaii, the character index (a number) was changed to character
label (a symbol) throughout the proposal.
>>
>> Page 25 section A.4.5 doesn't specify the syntax of a registry name; did
>> you intend it to be a string?
These have been changed to be symbols.
>>
>> Page 27 has an example using (typep x '(character "standard")) but
>> page 25 said that had to be a registry name; "standard" is not a
>> registry name.
The revision is clearer on this. character and characterp can take
registry names, :base or :standard. The meaning of :base and :standard
is defined by Common LISP as the base character repertoire and
standard character repertoire respectively.
>>
>> Page 29 - *ALL-REGISTER-NAMES* -- a list of strings?
Now a list of symbols.
>>
>> Page 33 -- FIND-CHAR -- does the index value within a registry have any
>> portable meaning? Is that intended to be specified for the standard
>> registries? Is "base" supposed to be accepted here? If not, how can
>> you access the base codes? If I were going to construct a character
>> from its index value, it would be more meaningful to use an index
>> relative to some coded character set rather than these registries.
FIND-CHAR takes a character label and registry. These are specified
by the registry standard. Base is not a registry name. We have
introduced a new function CHAR-CCS-VALUE which takes a character
object and a coded character set name (a symbol) and returns the
encoding of the character in the coded character set.
>>
>> Page 36, the last sentence doesn't make sense. The default for
>> :ELEMENT-TYPE would have to be either CHARACTER or BASE-CHARACTER.
Right. I've made this change.
>>
>> Page 37, section A.22.1.1 -- the part being deleted specifies the
>> meaning of including tab and form-feed characters in a Common Lisp
>> source file; do you really intend that to not have any standard meaning?
>> If my editor uses tabs for indenting, does that mean that the resulting
>> source file is not a standard-conforming program?
That really depends on the definition of a conforming program. Is
this defined yet?
>>
>> Page 38, the first reference to p360 of CLtL should be p353; the
>> deletion here says that there shall not be any standard name for the
>> commonly used control characters such as tab and form-feed. That still
>> seems wrong to me.
>>
>> Page 41, what's the point of appending "ccs" to the name of the
>> standard? Presumably that stands for "coded character set", but isn't
>> that adequately implied by the fact that this string will follow the
>> keyword :EXTERNAL-CODE-FORMAT ? The use of "default" seems odd since
>> :DEFAULT is used everywhere else.
This was to distinguish from someone referring to the set of characters
(repertoire) represented in a given coded character set. Ie. to
distinguish ISO8859/6-1987 coded character set from the ISO8850/6-1987
repertoire. In fact, the ISO coded character set standards never
refer to repertoires in isolation (ie. without the codes), so I've
dropped the 'ccs'. Also, "default" is now :DEFAULT as elsewhere.
>>
>> I agree with Moon that the excising of bits and fonts has not been done
>> carefully enough for them to be compatible extensions.
>>
I think the new revision takes care of this by incorporating the
attribute list as part of the language proper (ie. not deprecated).
∂22-Feb-89 1337 X3J13-mailer cs proposal part1 of 3
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 22 Feb 89 13:36:18 PST
Date: Wed, 22 Feb 89 10:06:36 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890222.100636.baggins@almvma>
Subject: cs proposal part1 of 3
\documentstyle{report} % Specifies the document style.
\pagestyle{headings}
\title{\bf
Extensions to Common LISP to Support International
Character Sets}
\author{
Michael Beckerle\thanks{Gold Hill Computers} \and
Paul Beiser\thanks{Hewlett-Packard} \and
Jerry Duggan\thanks{Hewlett-Packard} \and
Robert Kerns\thanks{Independent consultant} \and
Kevin Layer\thanks{Franz, Inc.} \and
Thom Linden\thanks{IBM Research, Subcommittee Chair} \and
Larry Masinter\thanks{Xerox Research} \and
David Unietis\thanks{Lucid, Inc.}
}
\date{February 21, 1989} % Deleting this command produces today's date.
\begin{document}
\maketitle % Produces the title.
\setcounter{secnumdepth}{4}
\setcounter{tocdepth}{4}
\tableofcontents
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\newfont{\cltxt}{cmr10}
\newfont{\clkwd}{cmtt10}
\newcommand{\apostrophe}{\clkwd '}
\newcommand{\bq}{\clkwd\symbol{'22}}
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\chapter{Introduction}
This is a proposal to the X3 J13 committee
for both extending and modifying the Common LISP
language definition to provide a standard basis for Common LISP
support of the variety of characters used to represent the
native languages of the international community.
This proposal was created by the Character Subcommittee of X3 J13.
We would like to acknowledge discussions with T. Yuasa and other
members of the JIS Technical Working Group,
comments from members of X3 J13,
and the proposals \cite{ida87},
\cite{linden87}, \cite{kerns87}, and \cite{kurokawa88} for
providing the motivation and direction for these extensions.
As all these documents and discussions were created
expressly for LISP standardization usage,
we have borrowed freely from their ideas as well as the texts
themselves.
This document is separated into two parts. The first part explains the
major language changes and their motivations. While intended as
commentary to a general audience, and not explicitly as
part of the standard document, the X3 J13 editor may
include sections at her/his discretion. The second part,
Appendix A, provides
the page by page set of editorial changes to \cite{steele84}.
\section{Objectives}
The major objectives of this proposal are:
\begin{itemize}
\item To provide a consistent, well-defined scheme allowing support
of both very large character sets and multiple character sets.
\footnote{The distinction between the terms {\em character repertoire}
and {\em coded character set} is made later. The usage
of the term {\em character set},
avoided after this introduction, encompasses both terms.}
Many software applications are intended for international use, or
have requirements for incorporation of language elements of multiple
native languages within a single application.
Also, many applications require specialized languages including,
for example, scientific and typesetting symbols.
In order
to ensure some portability of these applications, data expressed in
a mixture of these
languages must be treated uniformly by the
software language.
All character and string manipulations should operate uniformly,
regardless of the character set(s) of the character objects.
This applies to array indexing, readtable definitions, read
symbol construction and I/O operations.
\item To ensure efficient performance of string and character
operations.
Many native
languages, such as Japanese and Chinese, use character
sets which contain more characters than the Latin alphabet.
Supporting larger sized character sets frequently means employing
larger data fields to uniquely encode each character.
Common LISP implementations using
larger sized character sets can
incur performance penalties in terms
of space, time, or both.
The use of large and/or multiple character sets by an
implementation
implies the need for a more complex character type representation.
Given a more complex character representation, the efficiency
of language operations on characters (e.g. string operations)
could be affected.
\item To assure forward compatibility of the proposed model
and definition with existing Common LISP implementations.
Developers should not be required to re-write large amounts of either
LISP code or data representations in order to apply the proposed
changes to existing implementations.
The proposed changes should provide an easy
portability path for existing code to many possible implementations.
\end{itemize}
There are a number of issues, some under the general rubric of
internationalization, which this proposal does {\em not} cover.
Among these issues are:
\begin{itemize}
\item Time and date formats
\item Monetary formats
\item Numeric punctuation
\item Fonts
\item Lexicographic orderings
\item Right-to-left and bidirectional languages
\end{itemize}
%----------------------------------------------------------------------
%----------------------------------------------------------------------
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\chapter{Overview}
We use several terms within this document which
are new in the context of Common LISP.
Definitions for the following prominent
terms are provided for the reader's convenience.
A {\em character repertoire} defines a collection of characters
independent of their specific rendered image or font. This
corresponds to the mathematical notion of a {\em set}
\footnote{We avoid the term {\em character set} as it has been
(over)used in the context of character repertoire as well
as in the context of coded character set.}.
Character
repertoires are specified independent of coding and their characters
are only identified with a unique {\em character label},
a graphic symbol, and
a character description.
A {\em coded character set} is a character repertoire plus
an {\em encoding} providing a unique mapping between each character
and a number which serves as the character representation.
There are numerous internationally standardized coded character
sets; for example, \cite{iso8859/1} and \cite{iso646}.
A character may be included in one or more character repertoires.
Similarly, a character may be included in one or more
coded character sets. For example, the Latin letter "A" is contained
in the coded character set standards: ISO 8859/1, ISO 8859/2,
ISO 6937/2, and others.
To universally identify each character, we define a unique
collection of repertoires called {\em character
registries} as a partitioning of all characters.
That is, each character is included
in one and only one character registry.
In Common LISP a {\em character} data object is identified by its
{\em character code}, a unique numerical code.
Each character code is composed from
a character registry and a character label.
Character data objects which are classified as {\em graphic},
or displayable, are each associated with a {\em glyph}. The
glyph is the visual representation of the character.
The primary purpose of introducing these terms is to provide a
consistent naming to Common LISP concepts which are related
to those found in ISO standardization of coded
character sets.
\footnote{The bibliography includes several relevant ISO
coded character set standards.}
They also serve as a demarcation between these
standardization activities. For example, while Common LISP is free to
define unique manipulation facilities for characters, registries
and coded character sets, it should
not define standard coded character sets nor standard character
registries.
A secondary purpose is to detach the language specification from
underlying hardware representation. From a language
specification viewpoint it is inconsequential whether
characters occupy one or more (8-bit) bytes or whether
a Common LISP implementation's
internal representation for characters is distinct from or identical
to any of the numerous
external representations (for example, the text interchange
representation \cite{iso6937/2}).
We specifically do not propose any standard coded character sets.
%----------------------------------------------------------------------
\section{Character Identity}
Characters are uniquely distinguished by their codes,
which are drawn from the set of
non-negative integers. That is, within Common LISP
a unique numerical code
is assigned to each semantically different character.
It is important to separate the notion of glyph from the notion of
character data object when defining a scheme under which issues of
identity can be rigorously decided by a computer language. Glyphs are
the visual aspects of characters, writable on surfaces, and sometimes
called 'graphics'. A language specification valid for more than a
narrow range of systems can only make assumptions about the existence
of {\em abstract} glyphs (for example, the Latin letter A) and not about
glyph variants (for example, the italicized Latin letter {\em A})
or characteristics of display devices. Thus, an important element of
this proposal is the removal of the {\em font} and {\em bits}
attributes from the language specification.
\footnote{These and other attributes may still be supported as
implementation-defined extensions.}
All functions
dealing with the {\em bits} and {\em font} attributes are either
removed or modified by this proposal.
The deleted functions and constants include:
{\em char-font-limit,
char-bits-limit,
int-char,
char-int,
char-bits,
char-font,
make-char,
char-control-bit,
char-meta-bit,
char-super-bit,
char-hyper-bit,
char-bit,
set-char-bit}.
The definition in \cite{steele84} of semi-standard characters has
been eliminated. This is replaced by a more uniform approach
to character naming with the introduction of character registries
(see below).
%----------------------------------------------------------------------
\section{Character Naming}
A Common LISP program must be able to name, compose and decompose
characters in a uniform, portable manner, independent of any
underlying representation. One possible composition is by
the pair $<$ coded character set standard, decimal representation $>$
\footnote{This syntax is for illustration only and is not being
proposed.}.
Thus, for example, one might compose the Latin 'A' with the pair
$<$ ISO8859/2-1987, 65 $>$,
$<$ ISO8859/6-1987, 65 $>$, or
$<$ ISO646-1983, 65 $>$, etc.. The difficulty here is two-fold.
First, there are several ways to compose the same character and
second, there may be multiple answers to
the question: {\em To what coded character set
does character object x belong?}.\footnote{Even
worse, the answer might change yearly.}
The identical problems occur if the pair
$<$ character repertoire standard, decimal representation $>$ is used.
\footnote{Existing ISO repertoires seem to be defined exclusively
in the context of coded character sets and not as standards
in their own right.}
The concept of character registry is introduced by this proposal
to resolve the problem of character naming, composition and
decomposition.
Each character is universally defined by the
pair $<$ character registry name, character label $>$. For this
to be a portable definition, it must have a standard meaning.
Thus we propose the formation of an ISO Working Group to
define an international
{\em Character Registry Standard}.
At this writing there is no existing Character Registry Standard nor
ISO Working Group organized to define such a standard.
\footnote{It is the intention of X3 J13 to promote and adopt
an eventual ANSI or ISO Character Registry Standard. In particular, we
acknowledge that X3 J13 is {\em not} the appropriate forum to
define the standard. We believe
it is a required component of all programming languages
providing support for international characters.}
Common LISP character codes are composed from a character registry and
a character label. The convention by which a character label and
character registry compose a character code is implementation
dependent.
We introduce new functions {\clkwd find-char, char-registry-name,} and
{\clkwd char-label} to
compose and decompose character objects. We also extend the
{\clkwd characterp} predicate to
support testing
membership of a character in a given character registry.
\footnote{
For example,
testing membership in the Japanese Katakana character registry.
}
A global variable {\clkwd *all-character-registry-names*}
is added to
support application determination of supported character registries.
The naming and content of the standard character registries
is left unspecified by this proposal.
\footnote{The only constraint is that character registries be
named using only {\clkwd standard-p} characters.}
Below are some candidate character registry names:
\begin{itemize}
\item Arabic
\item Armenian
\item Bo-po-mo-fo
\item Control (meaning the collection of standard text communication
control codes)
\item Cyrillic
\item Georgian
\item Greek
\item Hangul
\item Hebrew
\item Hiragana
\item Japanese-Punctuation
\item Kanji
\item Katakana
\item Latin
\item Latin-Punctuation
\item Mathematical
\item Pattern
\item Phonetic
\item Technical
\end{itemize}
The list above is provided as a starting point for discussion
and is not intended to be representative
nor exhaustive. The Common LISP language definition does not
depend on these names nor any specific content (for example:
Where should the plus sign appear?). It is application
programs which require a reliable definition of the
registry names and their constituents. The Common LISP language
definition imposes the framework for constructing and manipulating
character objects.
The proposed ISO Character Registry Standard is fixed;
an implementation may not extend a standard registry's
constituent set of characters beyond the
standard definition.
An implementation may provide support for all or part of any
character registry
and may provide new character registries which include characters
having unique semantics (i.e. not defined in any standard
character registry).
Implementation registries must be uniquely
named using only {\clkwd standard-p} characters.
An implementation must document the registries it supports.
For each registry supported the documentation must include
at least the following:
\begin{itemize}
\item Character Labels,
Glyphs, and Descriptions.
\item Reader Canonicalization.
\item Effect of character predicates.
In particular,
\begin{itemize}
\item {\clkwd alpha-char-p}
\item {\clkwd lower-case-p}
\item {\clkwd upper-case-p}
\item {\clkwd both-case-p}
\item {\clkwd graphic-char-p}
\item {\clkwd alphanumericp}
\end{itemize}
\item Interaction with File I/O. In particular, the
coded character sets
\footnote{For example, ISO8859/1-1987.} and
external encoding schemes
\footnote{For example, {\em Xerox System Integration Character
Code Standard}\cite{xerox87}.}
supported are documented.
\end{itemize}
Which coded character sets and encoding schemes
are supported by the overall computing system, the
details of the mapping of glyphs to characters
to character codes are
left unspecified by Common LISP.
The diversity of glyph sets and coded character
set conventions in use worldwide and the desirability
of allowing Common LISP applications
to portabily manipulate symbolic elements from many
languages, perhaps simultaneously, mandate such a flexible approach.
%----------------------------------------------------------------------
\section{Hierarchy of Types}
Providing support for extensive character repertoires may
impact Common LISP implementation performance in terms
of space, time, or both.
\footnote{This does not apply to all implementations.
Unique hardware support and user community requirements must
be taken into consideration.}
In particular, many existing
implementations support variants of the ISO 8859/1 standard.
Supporting large
repertoires argues for a multi-byte internal representation
for each character, even if an application primarily (or exclusively)
uses the ISO 8859/1 characters.
This proposal extends the definition of the character and string
type hierarchy to include specialized subtypes
of character and string. An implementation is free to associate
compact internal representation tailored to each subtype.
The {\clkwd string} type specifier, when used for object
creation, for example in {\clkwd make-sequence},
is defined to mean the most general string subtype supported
by the implementation (similarily for the {\clkwd simple-string}
type specifier). This definition emphasizes portability
of existing Common LISP applications to international
character environments over performance. Applications emphasizing
efficiency of text processing in non-international environments
will require some modification to utilize subtypes with
compact internal representations.
It has been suggested that either a single type is
sufficient to support international characters,
or that a hierarchy of types could be used, in a manner
transparent to the user. A desire to provide flexibility which
encourages implementations to support international
characters without compromising application efficiency
led us to accept the need for more than one type.
We believe that these choices reflect a minimal
modification of this aspect of the type system, and that
exposing the types for string and character construction while
requiring uniform treatment for characters otherwise
is the most reasonable approach.
\subsection{Character Type}
The following type specifier is added as a subtype
of {\clkwd character}:
\begin{itemize}
\item {\clkwd base-character}
\end{itemize}
An implementation may support additional subtypes of {\clkwd character}
which may or may not be supertypes of {\clkwd base-character}.
In addition, an implementation may define {\clkwd base-character}
as equivalent to {\clkwd character}.
Characters of type {\clkwd base-character} are referred to as
{\em base characters}. Characters of type {\clkwd
(and character (not base-character))}
are referred to as {\em extended characters}.
The base characters are
distinguished in the following respects:
\begin{itemize}
\item
The standard characters are a subrepertoire of the base characters.
The selection of base characters which are not standard characters
is implementation defined.
\item
Only members of the base character repertoire
can be elements of a base string.
\item
The base characters are, in general, the default characters for I/O
operations.
\end{itemize}
No upper bound is specified for the number of glyphs in the base
character repertoire--that
is implementation dependent. The lower bound is 96, the
number of standard characters defined for Common LISP.
\footnote{Or, in contrast, the base repertoire may include all
implementation supported characters.}
The distinction of base characters is largely a pragmatic
choice. It permits efficient handling of common situations, is
in some sense privileged for host system I/O, and can serve as an
intermediate basis for portability, less general than the standard
characters, but possibly more useful across a narrower range of
implementations.
Many computers have some "base" character representation which
is a function of hardware instructions for dealing with characters,
as well as the organization of the file system. The base character
representation is likely to be the smallest transaction unit permitted
for text file and terminal I/O operations. On a system with a record
based I/O paradigm, the base character representation is likely to
be the smallest record quantum. On many computer systems,
this representation is a byte.
However, there are often multiple
coded character sets supportable on a
computer, through the use of special display and entry hardware, which
are varying interpretations of the basic system character
representation. For example, ISO 8859/1 and ISO 6937/2 are two
different interpretations of the same 1-byte code representations.
Many countries have their own glyph-to-code mappings for 1-byte
character codes addressing the special requirements of national
languages. Differentiating between these, without reference to
display hardware, is a matter of convention, since they all use the
same set of code representations. When a single byte is not enough,
two or more bytes are sometimes used for character encoding. This
makes character handling even more difficult on machines where the
natural representation size is a byte, since not only is the semantic
value of a character code a matter of convention, which may vary
within the same computing system, but so is the identification of a
set of bits as a complete character code.
It is the intention of this proposal that the composition of
base characters is typically
determined by the code capacity of the natural file system and I/O
transaction representations, and the assumed display glyphs should be
those of the terminals most commonly employed.
There are several advantages to this scheme. Internal representation
of strings of just base characters can be more compact than
strings including extended characters.
Source programs are likely to consist predominantly of base characters
since the standard characters are a subset of the base character
repertoire. Parsing of pure base character text
can be more efficient than parsing of text including
extended characters.
I/O can be performed more simply
with base characters.
The standard characters are the 96 characters used in the Common LISP
definition {\bf or their equivalents}.
This was the Common LISP \cite{steele84} definition, but
{\em equivalents} is a vague term.
The standard characters are not defined by their glyphs, but by their
roles within the language. There are two aspects to the roles of the
standard characters: one is their role in reader and format control
string syntax; the second is their role as components of the names of
all Common LISP
functions, macros, constants, and global variables. As
long as an implementation chooses 96 glyphs
and treats those 96 in a manner consistent with
the language's specification for the standard characters (e.g.
the naming of functions), it doesn't matter what glyphs the I/O
hardware uses to represent those characters: they are the standard
characters. Any program or
data text written wholly in those characters
is portable through simple code conversion.
\footnote{For example, the currency glyph, \$ , might be replaced
uniformly by the currency glyph available on a particular display.}
Additional
mechanisms, such as in \cite{linden87}, which support establishment of
equivalency between otherwise distinct characters are not excluded by
this proposal.
\footnote{We believe this is an important issue but it requires
additional implementation experience. We also encourage
new proposals from JIS and ISO LISP Working Groups on this issue.}
\subsection{String Type}
The {\clkwd string} type
is defined as
a vector of characters. More precisely, a string
is a specialized vector whose elements are of type
{\clkwd character} or a subtype of character. Similarly, a simple
string is a specialized simple vector whose elements are of type
{\clkwd character} or a subtype of character. The following string
subtypes are
distinguished with standardized names: {\clkwd base-string},
{\clkwd general-string}, {\clkwd simple-base-string}, and
{\clkwd simple-general-string}.
All strings which are not base strings
are referred to as {\em extended strings}.
A base string can only contain base characters.
{\clkwd general-string} is equivalent to {\clkwd (vector character)}
and can contain any implementation supported base or extended characters,
in any mixture.
All Common LISP functions defined to operate on strings treat
base and extended strings uniformly with the following
caveat: for any function which inserts a character into a string, it
is an error to insert an extended character
into a base string.
\footnote{An implementation may, optionally, provide automatic
coersion to an extended string.}
An implementation may support string subtypes in addition
to {\clkwd base-string} and
{\clkwd general-string}.
For example, a hypothetical
implementation supporting Arabic and Cyrillic character registries
might provide as extended characters:
\begin{itemize}
\item {\clkwd general-string} -- may contain Arabic, Cyrillic or
base characters in any mixture.
\item {\clkwd region-specialized-string} -- may contain installation
selected repertoire (Arabic/Cyrillic) or base characters in any
mixture.
\item {\clkwd base-string} -- may contain base characters
\end{itemize}
Though, clearly, portability of applications using
{\clkwd region-specialized-string} is limited, a performance
advantage might argue for its use.
\footnote{{\clkwd region-specialized-string} is used here for
illustration only; it is not being proposed as a standardized
string subtype.}
Alternatively,
an implementation
supporting a large base character repertoire
including, say, Japanese Kanji may define
{\clkwd base-character}
as equivalent to {\clkwd character}.
We expect that applications sensitive to the performance
of character handling in some host environments will
utilize the string subtypes to provide performance
improvement. Applications with emphasis on international
portability will likely utilize only {\clkwd general-string}s.
The {\clkwd coerce} function is extended to
allow for explicit coercion between base strings and extended strings.
It is an error to coerce an extended character to a base character.
During reader
construction of symbols, if all the characters
in the symbol's name are of type {\clkwd base-character},
then the name of the symbol may be stored as a base string.
Otherwise it will be stored as an extended string.
The base string type allows for more compact representation of strings
of base characters, which are likely to predominate in any system.
Note that in any particular implementation the base characters
need not be the
most compactly representable, since others might have
a smaller repertoire.
However, in most implementations base strings are
likely to be more space efficient than extended strings.
%----------------------------------------------------------------------
\section{Streams and System I/O}
A lot of the work of ensuring that a
Common LISP implementation operates correctly in a
multiple coded character set environment must be performed by
the I/O interface.
The system I/O interface, abstracted in
Common LISP as streams, is responsible
for ensuring that text input from outside LISP is properly mapped
into character objects internally, and that the inverse mapping
is performed on output. It is beyond the scope of a language
definition to specify the details of this operation, but options
are specified which allow runtime indication from the user as to
what coded character sets a stream uses, and how the mappings
should be done. It is expected that implementations will provide
reasonable defaults and invocation options to accommodate desired use
at an installation.
One keyword argument is proposed as an addition to {\clkwd open}:
\begin{itemize}
\item {\clkwd :external-coded-character-format}
whose value would be:
\begin{itemize}
\item
A name or list of names indicating an implementation recognized
scheme for representing 1 or more coded character sets.
\footnote{
For example, the so/si convention used by IBM on 370
machines could be selected by a list including
the name {\clkwd :ibm-shift-delimited}.
The run-encoding convention defined by XEROX could be
selected by {\clkwd :xerox-run-encoded}.
The convention based on
ASCII which uses leading bit patterns to distinguish two-byte codes
from one-byte codes could be selected by
{\clkwd :ascii-high-byte-delimited}.
}
As many coded character set names must be provided as the
implementation requires for that external coding convention.
\footnote{
For example, if {\clkwd :ibm-shift-delimited} were the
argument, two
coded character set specifiers would have to be provided.
}
\end{itemize}
\end{itemize}
These arguments are provided for input, output, and
bidirectional streams.
It is an error to try to write a character other than a
member of the specified coded character sets
to a stream. (This excludes the
\#$\backslash${\clkwd Newline} character.
Implementations must provide appropriate line division behavior
for all character streams.)
An implementation supporting multiple coded character sets
must allow for the external
representation of characters to be separately (and perhaps
multiply) specified to {\clkwd open},
since there can be circumstances under
which more than one external representation for characters
is in use, or more than one coded character set
is mixed together in an
external representation convention.
In addition to supporting conversion at the system interface, the
language must allow user programs to determine how much space data
objects will require when output in whichever external representations
are available.
The new function {\clkwd external-coded-string-length}
takes a character
or string object as its required argument. It also takes an optional
{\em output-stream}.
It returns the number of implementation-defined
representation units
\footnote{
Often the same as the storage width of a base character, usually a byte.
}
required to externally store that object, using the
representation convention associated with the stream.
If the object cannot be represented in
that convention, the function returns {\clkwd nil}.
This function is necessary
to determine if strings can be written to fixed length
fields in databases or terminal screen templates. Note that this
function does not
address the problem of calculating
screen width of strings printed in proportional fonts.
Related to the I/O interface,
we also introduce the function {\clkwd char-ccs-value}
which takes a character object and a coded character set name
(eg. {\clkwd :ISO8859/1-1987}) and returns the encoding of
the character within the coded character set.
%----------------------------------------------------------------------
%----------------------------------------------------------------------
∂22-Feb-89 1338 X3J13-mailer cs proposal part 2 of 3
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 22 Feb 89 13:37:30 PST
Date: Wed, 22 Feb 89 10:08:21 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890222.100821.baggins@almvma>
Subject: cs proposal part 2 of 3
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\newcommand{\edithead}{\begin{tabular}{l p{3.95in}}
\multicolumn{2}{l} }
\newcommand{\csdag}{\bf$\Rightarrow$\ddag}
\newcommand{\editstart}{}
\newcommand{\editend}{\\ & \end{tabular}}
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\appendix
\chapter{Editorial Modifications to CLtL}
The following sections specify the editorial changes needed in
CLtL to support the proposal. Section/subsection numbers and titles
match those found in \cite{steele84}. The notation
{\csdag x (pn, function)} denotes a reference to paragraph x within the
subsection (we count each individual example or metastatement
as 1 paragraph of text). Also, {\bf (pn, function)}, or simply
{\bf (pn)} is included as an additional
aid to the reader indicating the page number and function modified.
When an entire paragraph is deleted,
the first few words of the paragraph is noted.
If a section or paragraph of CLtL is {\em not} referenced,
no editorial changes are required to support this proposal.
\footnote{This may be an over optimistic statement since the changes
are fairly pervasive. The editor should take the sense of
Chapter 1 into account in resolving any discrepancies.}
%----------------------------------------------------------------------
\setcounter{section}{1}
\section{Data Types} % 2
%----------------------------------------------------------------------
\edithead {\csdag 8 (p12)}
\editstart
\\ \bf replace &
\cltxt
provides for a
rich character set, including ways to represent characters of various
type styles.
\\ \bf with &
\cltxt
provides support for international language characters as well
as characters used in specialized arenas, eg. mathematics.
\editend
\setcounter{subsection}{1}
\subsection{Characters} % 2.2.
\edithead {\csdag 1 (p20)}
\editstart
\\ \bf replace &
\cltxt
Characters are represented as data objects of type {\clkwd character}.
There are two subtypes of interest, called
{\clkwd standard-char} and {\clkwd string-char}.
\\ \bf with &
\cltxt
Characters are represented as data objects of type
{\clkwd character}.
\editend
\\
\edithead {\csdag 2 (p20)}
\editstart
\\ \bf replace &
\cltxt
This works well enough for printing characters. Non-printing
characters
\\ \bf with &
\cltxt
This works well enough for graphic characters. Non-graphic
characters
\editend
\subsubsection{Standard Characters} % 2.2.1.
\edithead {\csdag 1 before (p20)}
\editstart
\\ \bf insert &
\cltxt
A {\em character repertoire} defines a collection of characters
independent of their specific rendered image or font.
Character
repertoires are specified independent of coding and their characters
are only identified with a unique label, a graphic symbol, and
a character description.
A {\em coded character set} is a character repertoire plus
an {\em encoding} providing a unique mapping between each character
and a number which serves as the character representation.
\\ &
Common LISP requires all implementations to support a {\em standard}
character subrepertoire. Typically, an implementation
incorporates the standard
characters as a subset of a larger repertoire corresponding
to a frequently used set of characters, or base coded character
set.
The term {\em base character repertoire} refers to
the collection of characters represented by
the base coded character set.
\editend
\\
\edithead {\csdag 1 before (p20)}
\editstart
\\ \bf insert &
\cltxt
The {\clkwd base-character} type is defined as a subtype of
{\clkwd character}. A {\clkwd base-character}
object can contain any member of the base character repertoire.
Objects of type
{\clkwd (and character (not base-character))} are referred to
as {\em extended characters}.
\editend
\\
\edithead {\csdag 1 (p20)}
\editstart
\\ \bf delete &
\cltxt
Common LISP defines a "standard character set" ...
\editend
\\
\edithead {\csdag 1 (P20)}
\editstart
\\ \bf new &
\cltxt
The Common LISP
standard character subrepertoire consists of
a newline \#$\backslash${\clkwd Newline}, the
graphic space character \#$\backslash${\clkwd Space},
and the following additional
ninety-four graphic characters or their equivalents:
\editend
\\
\edithead {\csdag 2 (p21)}
\editstart
\\ \bf delete &
\cltxt
! " \# ...
\editend
\\
\edithead {\csdag 2 new (p21)}
\editstart
\\ &
{\bf Common LISP Standard Character Subrepertoire}
\editend
\footnote{\cltxt \#$\backslash${\clkwd Space}
and \#$\backslash${\clkwd Newline} are omitted.
graphic labels and descriptions are from ISO 6937/2.
The first letter of the graphic label categorizes the
character as follows: L - Latin, N - Numeric, S - Special
.}
\\
{\small \begin{tabular}{||l|c|l||l|c|l||} \hline
Label & Glyph & Name or description
& Label & Glyph & Name or description
\\ \hline
LA01 & a & small a
& ND01 & 1 & digit 1
\\ \hline
LA02 & A & capital A
& ND02 & 2 & digit 2
\\ \hline
LB01 & b & small b
& ND03 & 3 & digit 3
\\ \hline
LB02 & B & capital B
& ND04 & 4 & digit 4
\\ \hline
LC01 & c & small c
& ND05 & 5 & digit 5
\\ \hline
LC02 & C & capital C
& ND06 & 6 & digit 6
\\ \hline
LD01 & d & small d
& ND07 & 7 & digit 7
\\ \hline
LD02 & D & capital D
& ND08 & 8 & digit 8
\\ \hline
LE01 & e & small e
& ND09 & 9 & digit 9
\\ \hline
LE02 & E & capital E
& ND10 & 0 & digit 0
\\ \hline
LF01 & f & small f
& SC03 & \$ & dollar sign
\\ \hline
LF02 & F & capital F
& SP02 & ! & exclamation mark
\\ \hline
LG01 & g & small g
& SP04 & " & quotation mark
\\ \hline
LG02 & G & capital G
& SP05 & \apostrophe & apostrophe
\\ \hline
LH01 & h & small h
& SP06 & ( & left parenthesis
\\ \hline
LH02 & H & capital H
& SP07 & ) & right parenthesis
\\ \hline
LI01 & i & small i
& SP08 & , & comma
\\ \hline
LI02 & I & capital I
& SP09 & \_ & low line
\\ \hline
LJ01 & j & small j
& SP10 & - & hyphen or minus sign
\\ \hline
LJ02 & J & capital J
& SP11 & . & full stop, period
\\ \hline
LK01 & k & small k
& SP12 & / & solidus
\\ \hline
LK02 & K & capital K
& SP13 & : & colon
\\ \hline
LL01 & l & small l
& SP14 & ; & semicolon
\\ \hline
LL02 & L & capital L
& SP15 & ? & question mark
\\ \hline
LM01 & m & small m
& SA01 & + & plus sign
\\ \hline
LM02 & M & capital M
& SA03 & $<$ & less-than sign
\\ \hline
LN01 & n & small n
& SA04 & = & equals sign
\\ \hline
LN02 & N & capital N
& SA05 & $>$ & greater-than sign
\\ \hline
LO01 & o & small o
& SM01 & \# & number sign
\\ \hline
LO02 & O & capital O
& SM02 & \% & percent sign
\\ \hline
LP01 & p & small p
& SM03 & \& & ampersand
\\ \hline
LP02 & P & capital P
& SM04 & * & asterisk
\\ \hline
LQ01 & q & small q
& SM05 & @ & commercial at
\\ \hline
LQ02 & Q & capital Q
& SM06 & [ & left square bracket
\\ \hline
LR01 & r & small r
& SM07 & $\backslash$ & reverse solidus
\\ \hline
LR02 & R & capital R
& SM08 & ] & right square bracket
\\ \hline
LS01 & s & small s
& SM11 & \{ & left curly bracket
\\ \hline
LS02 & S & capital S
& SM13 & $|$ & vertical bar
\\ \hline
LT01 & t & small t
& SM14 & \} & right curly bracket
\\ \hline
LT02 & T & capital T
& SD13 & \bq & grave accent
\\ \hline
LU01 & u & small u
& SD15 & $\hat{ }$ & circumflex accent
\\ \hline
LU02 & U & capital U
& SD19 & $\tilde{ }$ & tilde
\\ \hline
LV01 & v & small v
& & &
\\ \hline
LV02 & V & capital V
& & &
\\ \hline
LW01 & w & small w
& & &
\\ \hline
LW02 & W & capital W
& & &
\\ \hline
LX01 & x & small x
& & &
\\ \hline
LX02 & X & capital X
& & &
\\ \hline
LY01 & y & small y
& & &
\\ \hline
LY02 & Y & capital Y
& & &
\\ \hline
LZ01 & z & small z
& & &
\\ \hline
LZ02 & Z & capital Z
& & &
\\
\hline
\end{tabular} }
\\
\edithead {\csdag 3 (p21)}
\editstart
\\ \bf delete &
\cltxt
@ A B C...
\editend
\\
\edithead {\csdag 4 (p21)}
\editstart
\\ \bf delete &
\cltxt
\bq a b c...
\editend
\\
\edithead {\csdag 5 (p21)}
\editstart
\\ \bf delete &
\cltxt
The Common LISP Standard character set is apparently ...
\editend
\\
\edithead {\csdag 6 (p21)}
\editstart
\\ \bf replace &
\cltxt
Of the ninety-four non-blank printing characters
\\ \bf with &
\cltxt
Of the ninety-five graphic characters
\editend
\\
\edithead {\csdag 9 (p21)}
\editstart
\\ \bf delete &
\cltxt
The following characters are called ...
\editend
\\
\edithead {\csdag 10 (p21)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd \#$\backslash$Backspace \#$\backslash$Tab } ...
\editend
\\
\edithead {\csdag 11 (p21)}
\editstart
\\ \bf delete &
\cltxt
Not all implementations of Common ...
\editend
\subsubsection{Line Divisions} % 2.2.2.
\edithead {\csdag 6 (p22)}
\editstart
\\ \bf replace &
\cltxt
a two-character sequence, such as
{\clkwd \#$\backslash$Return } and then
{\clkwd \#$\backslash$Newline },
is not acceptable,
\\ \bf with &
\cltxt
a two-character sequence is not acceptable,
\editend
\\
\edithead {\csdag 8 (p22)}
\editstart
\\ \bf delete &
\cltxt
Implementation note: If an implementation uses ...
\editend
\subsubsection{Non-standard Characters} % 2.2.3.
\edithead {\csdag delete entire section (p23)}
\editstart
\editend
\subsubsection{Character Attributes} % 2.2.4.
\edithead {\csdag 0 section heading (p23)}
\editstart
\\ \bf replace &
\cltxt
Character Attributes
\\ \bf with &
\cltxt
Character Identity
\editend
\\
\edithead {\csdag 1 through 8 (p23)}
\editstart
\\ \bf delete all paragraphs&
\cltxt
Every object of type {\clkwd character} ...
\editend
\\
\edithead {\csdag 1 (p23)}
\editstart
\\ \bf new &
\cltxt
Characters are uniquely distinguished by their codes,
which are drawn from the set of
non-negative integers. That is, within Common LISP
a unique numerical code
is assigned to each semantically different character.
\\ &
Common LISP
characters are partitioned into a unique collection of
repertoires called {\em
character registries}. That is, each character is included
in one and only one character registry.
\\ &
Character codes are composed from a character registry and a
character label. The convention by which a character registry and
character label compose a character code is implementation
dependent.
\editend
\subsubsection{String Characters} % 2.2.5.
\edithead {\csdag delete entire section (p23)}
\editstart
\editend
\setcounter{subsection}{4}
\subsubsection{Character Registries} % 2.2.5.
\edithead {\csdag new section (p23)}
\editstart
\\ \bf new &
\cltxt
An implementation must document the registries it supports.
Registries must be uniquely
named using only {\clkwd standard-p} characters.
For each registry supported,
an implementation must define the individual characters supported
including at least the following:
\begin{itemize}
\item Character Labels,
Glyphs, and Descriptions.
\item Reader Canonicalization.
\item Effect of character predicates.
\begin{itemize}
\item {\clkwd alpha-char-p}
\item {\clkwd lower-case-p}
\item {\clkwd upper-case-p}
\item {\clkwd both-case-p}
\item {\clkwd graphic-char-p}
\item {\clkwd alphanumericp}
\end{itemize}
\item Interaction with File I/O. In particular, the
coded character set standards
\footnote{For example, ISO8859/1-1987.} and
external encoding schemes
which are supported must be specified.
\end{itemize}
\editend
\subsection{Symbols} % 2.3.
\edithead {\csdag 12 (p25)}
\editstart
\\ \bf replace &
\cltxt
A symbol may have uppercase letters, lowercase letters, or both
in its print name.
\\ \bf with &
\cltxt
A symbol may have characters from any supported character registry
in its print name.
It may have uppercase letters, lowercase letters, or both.
\editend
\setcounter{subsection}{4}
\subsection{Arrays}
\subsubsection{Vectors}
\edithead {\csdag 6 (p29)}
\editstart
\\ \bf replace &
\cltxt
All implementations provide specialized arrays for the cases when
the components are characters (or rather, a special subset of the
characters);
\\ \bf with &
\cltxt
All implementations provide specialized arrays for the cases when
the components are characters (or optionally, special subsets of
the characters);
\editend
\subsubsection{Strings}
\edithead {\csdag 1 (p30)}
\editstart
\\ \bf replace &
\cltxt
A string is simply a vector of characters. More precisely, a string
is a specialized vector whose elements are of type
{\clkwd string-char}.
\\ \bf with &
\cltxt
A string is simply a vector of characters. More precisely, a string
is a specialized vector whose elements are of type
{\clkwd character} or a subtype
of character.
\editend
\setcounter{subsection}{14}
\subsection{Overlap, Inclusion, and Disjointness of Types} % 2.15.
\edithead {\csdag 14 (p34)}
\editstart
\\ \bf replace &
\cltxt
The type {\clkwd standard-char} is a subtype of {\clkwd string-char};
{\clkwd string-char} is a subtype of {\clkwd character}.
\\ \bf with &
\cltxt
The type {\clkwd base-character} is a subtype of
{\clkwd character}.
The type {\clkwd string-char} is implementation defined as either
{\clkwd base-character} or {\clkwd character}.
\editend
\\
\edithead {\csdag 15 (p34)}
\editstart
\\ \bf replace &
\cltxt
The type {\clkwd string} is a subtype of {\clkwd vector},
for {\clkwd string} means {\clkwd (vector string-char)}.
\\ \bf with &
\cltxt
The type {\clkwd string} is a subtype of {\clkwd vector},
{\clkwd string} consists of vectors specialized by subtypes of
{\clkwd character}.
\editend
\\
\edithead {\csdag 15 after (p34)}
\editstart
\\ \bf insert &
\cltxt
The type {\clkwd base-string} means
{\clkwd (vector base-character)}.
\editend
\\
\edithead {\csdag 15 after (p34)}
\editstart
\\ \bf insert &
\cltxt
The type {\clkwd general-string} means
{\clkwd (vector character)} and is a subtype of {\clkwd string}.
\editend
\\
\edithead {\csdag 20 (p34)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd (simple-array string-char (*))};
\\ \bf with &
\cltxt
{\clkwd (and string simple-array)};
\editend
\\
\edithead {\csdag 20 after (p34)}
\editstart
\\ \bf insert &
\cltxt
The type {\clkwd simple-base-string} means
{\clkwd (simple-array base-character (*))} and
is the most efficient string which can hold
the standard characters. {\clkwd simple-base-string}
is a subtype of {\clkwd base-string}.
\editend
\\
\edithead {\csdag 20 after (p34)}
\editstart
\\ \bf insert &
\cltxt
The type {\clkwd simple-general-string} means
{\clkwd (simple-array character (*))}.
{\clkwd simple-general-string}
is a subtype of {\clkwd general-string}.
\editend
\\
\edithead {\csdag 22 after (p34)}
\editstart
\\ \bf replace &
\cltxt
The type {\clkwd simple-string} is a subtype of
{\clkwd string}. (Note that although
{\clkwd string}
is a subtype of {\clkwd vector, simple-string} is not
a subtype of {\clkwd simple-vector}.
\\ \bf with &
\cltxt
The type {\clkwd simple-string} is a subtype of
{\clkwd string}, {\clkwd simple-string} consists of
simple vectors specialized by subtypes of
{\clkwd character}. (Note that although
{\clkwd string}
is a subtype of {\clkwd vector, simple-string} is not
a subtype of {\clkwd simple-vector}.
\editend
%----------------------------------------------------------------------
\setcounter{section}{3}
\section{Type Specifiers} % 4
%----------------------------------------------------------------------
\setcounter{subsection}{1}
\subsection{Type Specifier Lists} % 4.2.
\edithead {\csdag 8 Table 4-1 (alphabetic list) (p43)}
\editstart
\\ \bf remove &
\\ &
\cltxt
{\clkwd standard-char}
\\ &
{\clkwd string-char}
\editend
\\
\edithead {\csdag 8 Table 4-1 (alphabetic list) (p43)}
\editstart
\\ \bf insert &
\\ &
\cltxt
{\clkwd base-character}
\\ &
{\clkwd base-string}
\\ &
{\clkwd general-string}
\\ &
{\clkwd simple-base-string}
\\ &
{\clkwd simple-general-string}
\editend
\setcounter{subsection}{2}
\subsection{Predicating Type Specifiers} % 4.3.
\edithead {\csdag 2 (p43)}
\editstart
\\ \bf delete &
\cltxt
As an example, the entire ...
\editend
\\
\edithead {\csdag 3 delete example (p43)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd (deftype string-char () } ...
\editend
\setcounter{subsection}{4}
\subsection{Type Specifiers That Specialize} % 4.5.
\edithead {\csdag 5 after (p46)}
\editstart
\\ \bf insert &
\cltxt
{\clkwd (character {\em repertoire})}
\\ &
This denotes a character type specialized to members
of the specified repertoire. {\em Repertoire} may be
{\clkwd :base} or {\clkwd :standard} or any supported
character registry name or a list of names.
\editend
\setcounter{subsection}{5}
\subsection{Type Specifiers That Abbreviate} % 4.6.
\edithead {\csdag 20 (p49)}
\editstart
\\ \bf replace &
\cltxt
Means the same as {\clkwd (array string-char ({\em size}))}: the set of
strings of
the indicated size.
\\ \bf with &
\cltxt
Means the union of the vector types specialized by subtypes of
character
and the indicated size.
For the purpose of object creation, it is equivalent to
{\clkwd (general-string ({\em size}))}.
\editend
\\
\edithead {\csdag 23 (p49)}
\editstart
\\ \bf replace &
\cltxt
Means the same as {\clkwd (simple-array string-char ({\em size}))}: the
set of simple strings of the indicated size.
\\ \bf with &
\cltxt
Means the union of the simple vector types specialized by subtypes of
character and the indicated size.
For the purpose of object creation, it is equivalent to
{\clkwd (simple-general-string ({\em size}))}.
\editend
\\
\edithead {\csdag 23 after (p49)}
\editstart
\\ \bf insert &
\cltxt
{\clkwd (base-string {\em size})}
\\ &
Means the same as {\clkwd (array base-character ({\em size}))}: the
set of base strings of the indicated size.
\\ &
{\clkwd (simple-base-string {\em size})}
\\ &
Means the same as {\clkwd (simple-array base-character ({\em size}))}:
the set of simple base strings of the indicated size.
\editend
\\
\edithead {\csdag 23 after (p49)}
\editstart
\\ \bf insert &
\cltxt
{\clkwd (general-string {\em size})}
\\ &
Means the same as {\clkwd (array character ({\em size}))}: the
set of base strings of the indicated size.
\\ &
{\clkwd (simple-general-string {\em size})}
\\ &
Means the same as
{\clkwd (simple-array general-character ({\em size}))}:
the set of simple general strings of the indicated size.
\editend
\setcounter{subsection}{7}
\subsection{Type Conversion Function} % 4.8.
\edithead {\csdag 6 (p51)}
\editstart
\\ \bf replace &
\cltxt
Some strings, symbols, and integers may be converted to
characters. If {\em object} is a string of length 1,
then the sole element of the print name is returned.
If {\em object} is a symbol whose print name is of length
1, then the sole element of the print name is returned.
If {\em object} is an integer {\em n}, then {\clkwd (int-char }
{\em n}{\clkwd )} is returned. See {\clkwd character}.
\\ \bf with &
\cltxt
Some strings amd symbols may be converted to
characters. If {\em object} is a string of length 1,
then the sole element of the print name is returned.
If {\em object} is a symbol whose print name is of length
1, then the sole element of the print name is returned.
See {\clkwd character}.
\editend
\\
\edithead {\csdag 6 after (p52)}
\editstart
\\ \bf insert &
\begin{itemize}
\cltxt
\item Any string subtype may be converted to any other string
subtype, provided the new string can contain all actual
elements of the old string. It is an error if it cannot.
\end{itemize}
\editend
%----------------------------------------------------------------------
\setcounter{section}{5}
\section{Predicates} % 6
%----------------------------------------------------------------------
\edithead {\csdag 2 (p71)}
\editstart
\\ \bf replace &
\cltxt
but {\clkwd standard-char} begets {\clkwd standard-char-p}
\\ \bf with &
\cltxt
but {\clkwd bit-vector} begets {\clkwd bit-vector-p}
\editend
\setcounter{subsection}{1}
\subsection{Data Type Predicates} % 6.2.
\setcounter{subsubsection}{1}
\subsubsection{Specific Data Type Predicates} % 6.2.2.
\edithead {\csdag 36 (p75)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd characterp} {\em object}
\\ \bf with &
\cltxt
{\clkwd characterp} {\em object} \&{\clkwd optional}
{\em repertoire}
\editend
\\
\edithead {\csdag 37 (p75)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd characterp} is true if its argument is a character,
and otherwise is false.
\\ \bf with &
\cltxt
If {\em repertoire} is omitted, {\clkwd characterp}
is true if its argument is a character object,
and otherwise is false.
If a {\em repertoire} argument is specified,
{\clkwd characterp} is true if its argument
is a character object and a member of the specified repertoire,
and
otherwise is false.
For example, {\clkwd (characterp \#$\backslash$A}
{\clkwd :Latin)}
is true since \#$\backslash$A is a member of the
Latin character registry. {\em repertoire} may be any supported
character registry name or the names
{\clkwd :base} or {\clkwd :standard}. {\clkwd (characterp x :base)} is
true if its argument is a member of the base character
repertoire and false
otherwise.
{\clkwd (characterp x :standard)} is
true if its argument is a member of the standard character
subrepertoire and false
otherwise.
\editend
\\
\edithead {\csdag 38 (p75)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd (characterp x) $\equiv$ (typep x \apostrophe character)}
\\ \bf with &
\cltxt
{\clkwd (characterp x :standard) $\equiv$ (typep x \apostrophe
(character :standard)}
\editend
\\
\edithead {\csdag 72 (p76)}
\editstart
\\ \bf replace &
\cltxt
See also {\clkwd standard-char-p, string-char-p, streamp,}
\\ \bf with &
\cltxt
See also {\clkwd standard-char-p, streamp,}
\editend
\setcounter{subsubsection}{2}
\subsubsection{Equality Predicates} % 6.2.3.
\edithead {\csdag 75 (p81)}
\editstart
\\ \bf replace &
\cltxt
which ignores alphabetic case and certain other attributes
of characters;
\\ \bf with &
\cltxt
which ignores alphabetic case
of characters;
\editend
%----------------------------------------------------------------------
\setcounter{section}{6}
\section{Control Structure} % 7
%----------------------------------------------------------------------
\setcounter{subsection}{1}
\subsection{Generalized Variables} % 7.2.
\edithead {\csdag 19 modify table (p95)}
\editstart
\\ \bf replace &
\cltxt
char string-char
\\ &
schar string-char
\\ \bf with &
\cltxt
char character
\\ &
schar character
\editend
\\
\edithead {\csdag 22 table entry (p96)}
\editstart
\\ \bf delete &
\cltxt
char-bit first set-char-bit
\editend
%----------------------------------------------------------------------
\setcounter{section}{9}
\section{Symbols} % 10
%----------------------------------------------------------------------
\edithead {\csdag 3 (p163)}
\editstart
\\ \bf replace &
\cltxt
It is ordinarily not permitted to alter a symbol's print name.
\\ \bf with &
\cltxt
It is an error to alter a symbol's print name.
\editend
\setcounter{subsection}{1}
\subsection{The Print Name} % 10.2.
\edithead {\csdag 5 (p168)}
\editstart
\\ \bf replace &
\cltxt
It is an extremely bad idea
\\ \bf with &
\cltxt
It is an error and an extremely bad idea
\editend
%----------------------------------------------------------------------
\setcounter{section}{10}
\section{Packages} % 11
%----------------------------------------------------------------------
\setcounter{subsection}{6}
\subsection{Package System Functions and Variables} % 11.7.
\edithead {\csdag 31 (p184,intern)}
\editstart
\\ \bf append &
\cltxt
All strings, base and extended, are acceptable {\em string}
arguments.
\editend
∂22-Feb-89 1339 X3J13-mailer cs proposal part 3 of 3
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 22 Feb 89 13:38:49 PST
Date: Wed, 22 Feb 89 10:08:51 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890222.100851.baggins@almvma>
Subject: cs proposal part 3 of 3
%----------------------------------------------------------------------
\setcounter{section}{12}
\section{Characters} % 13
%----------------------------------------------------------------------
\edithead {\csdag 6 after (p233)}
\editstart
\\ \bf insert &
\cltxt
{\clkwd char-code-limit} [{\clkwd Constant}]
\\ &
The value of {\clkwd char-code-limit} is a non-negative integer
that is the upper exclusive bound on values produced by the
function {\clkwd char-code}, which returns the {\em code}
of a given character; that is, the values returned by
{\clkwd char-code} are non-negative and strictly less than
the value of {\clkwd char-code-limit}.
There may be unassigned codes between 0 and
{\clkwd char-code-limit} which
are not legal arguments to {\clkwd code-char}.
\\ &
\cltxt
{\clkwd *all-character-registry-names*} [{\clkwd Variable}]
\\ &
The value of {\clkwd *all-character-registry-names*} is a list of
all character registry names supported by the implementation.
\editend
\setcounter{subsection}{0}
\subsection{Character Attributes} % 13.1.
\edithead {\csdag replace entire section (p233)}
\editstart
\\ \bf with &
\cltxt
Earlier versions of Common LISP incorporated {\em font} and
{\em bits} as attributes of character objects. These are
considered implementation-defined attributes and
if supported by an implementation
effect the action of selected functions. In particular,
the following effects are noted:
\\ &
\begin{itemize}
\item Attributes, such as those
dealing with how the character is displayed or its typography,
are not part of the character code.
For example, bold-face, color
or size are not considered part of the character code.
\item If two characters differ in any attributes,
then they are not {\clkwd char=}.
\item If two characters have identical
attributes, then their ordering by
{\clkwd char}$<$ is consistent with the numerical ordering by the
predicate $<$ on
their code attributes. (Similarly for {\clkwd char}$>$,
{\clkwd char}$>=$ and {\clkwd char}$<=$.)
\item The effect, if any, on {\clkwd char-equal} of each
attribute has to be specified as part of
the definition of that attribute.
\item The effect of {\clkwd char-upcase} and {\clkwd char-downcase}
is to preserve attributes.
\item The function {\clkwd char-int} is equivalent to {\clkwd char-code}
if no attributes are associated with
the character object.
\item The function {\clkwd int-char} is equivalent to {\clkwd code-char}
if no attributes are associated with
the character object.
\item It is implementation dependent whether characters within
double quotes have attributes removed.
\item It is implementation dependent whether
attributes are removed from symbol names by {\clkwd read}.
\end{itemize}
\editend
\setcounter{subsection}{1}
\subsection{Predicates on Characters} % 13.2.
\edithead {\csdag 3 (p234)}
\editstart
\\ \bf replace &
\cltxt
argument is a "standard character" that is, an object of type
{\clkwd standard-char}.
Note that any character with a non-zero {\em bits} or {\em font}
attribute
is non-standard.
\\ \bf with &
\cltxt
argument is one of the Common LISP standard character subrepertoire.
\editend
\\
\edithead {\csdag 4 (p234)}
\editstart
\\ \bf delete &
\cltxt
Note that any character with non-zero ...
\editend
\\
\edithead {\csdag 6 (p235)}
\editstart
\\ \bf replace &
\cltxt
Of the standard characters all but \#$\backslash${\clkwd Newline}
are graphic.
The semi-standard characters \#$\backslash${\clkwd Backspace},
\#$\backslash${\clkwd Tab},
\#$\backslash${\clkwd Rubout},
\#$\backslash${\clkwd Linefeed},
\#$\backslash${\clkwd Return},
and \#$\backslash${\clkwd Page} are not graphic.
\\ \bf with &
\cltxt
Of the standard characters all but \#$\backslash${\clkwd Newline}
are graphic.
\editend
\\
\edithead {\csdag 7 (p235)}
\editstart
\\ \bf delete &
\cltxt
Programs may assume that graphic ...
\editend
\\
\edithead {\csdag 8 (p235)}
\editstart
\\ \bf delete &
\cltxt
Any character with a non-zero bits...
\editend
\\
\edithead {\csdag 9 (p235)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd string-char-p} ...
\editend
\\
\edithead {\csdag 10 (p235)}
\editstart
\\ \bf delete &
\cltxt
The argument {\em char} must be ...
\editend
\\
\edithead {\csdag 13 (p235)}
\editstart
\\ \bf replace &
\cltxt
If a character is alphabetic, then it is perforce graphic. Therefore
any character
with a non-zero bits attribute cannot be alphabetic. Whether a
character is
alphabetic is may depend on its font number.
\\ \bf with &
\cltxt
If a character is alphabetic, then it is perforce graphic.
\editend
\\
\edithead {\csdag 22 (p236)}
\editstart
\\ \bf replace &
\cltxt
If a character is either uppercase or lowercase, it is necessarily
alphabetic (and
therefore is graphic, and therefore has a zero bits attribute).
However, it is permissible in theory for an alphabetic character
to be neither
uppercase nor lowercase (in a non-Roman font, for example).
\\ \bf with &
\cltxt
If a character is either uppercase or lowercase, it is necessarily
alphabetic (and
therefore is graphic).
\editend
\\
\edithead {\csdag 25 (p236)}
\editstart
\\ \bf replace &
\cltxt
The argument {\em char} must be a character object, and {\em radix}
must be a non-negative
integer. If {\em char} is not a digit of the radix specified
\\ \bf with &
\cltxt
The argument {\em char} must be in the standard character
subrepertoire and
{\em radix} must be a non-negative integer.
If {\em char} is not a standard character or is not a digit of the
radix specified
\editend
\\
\edithead {\csdag 51 (p237)}
\editstart
\\ \bf delete &
\cltxt
If two characters have the same bits ...
\editend
\\
\edithead {\csdag 52 (p237)}
\editstart
\\ \bf replace &
\cltxt
If two characters differ in any attribute (code, bits, or font), then
they are different.
\\ \bf with &
\cltxt
If the codes of two characters differ, then
they are different.
\editend
\\
\edithead {\csdag 94 (p239)}
\editstart
\\ \bf replace &
\cltxt
The predicate {\clkwd char-equal} is like {\clkwd char=}, and
similarly for the others, except
according to a different ordering such that differences of bits
attributes and case are ignored, and font information is taken into
account in an implementation dependent manner.
\\ \bf with &
\cltxt
The predicate {\clkwd char-equal} is like {\clkwd char=}, and
similarly for the others, except
according to a different ordering such that differences of case
are ignored.
\editend
\\
\edithead {\csdag 97 example (p239)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd (char-equal \#$\backslash$A \#$\backslash$Control-A) is true}
\editend
\\
\edithead {\csdag 98 (p239)}
\editstart
\\ \bf delete &
\cltxt
The ordering may depend on the font ...
\editend
\setcounter{subsection}{2}
\subsection{Character Construction and Selection} % 13.3.
\edithead {\csdag 3 (p239)}
\editstart
\\ \bf replace &
\cltxt
The argument {\em char} must be a character object.
{\clkwd char-code} returns the {\em code} attribute of the
character object;
this will be a non-negative integer less than the (normal) value
\\ \bf with &
\cltxt
The argument {\em char} must be a character object.
{\clkwd char-code} returns the {\em code} of the
character object;
this will be a non-negative integer less than the value
\editend
\\
\edithead {\csdag 4 (p240)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd char-bits } ...
\editend
\\
\edithead {\csdag 5 (p240)}
\editstart
\\ \bf delete &
\cltxt
The argument {\em char} must be ...
\editend
\\
\edithead {\csdag 6 (p240)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd char-font } ...
\editend
\\
\edithead {\csdag 7 (p240)}
\editstart
\\ \bf delete &
\cltxt
The argument {\em char} must be ...
\editend
\\
\edithead {\csdag 8 (p240)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd code-char {\em code} \&optional {\em (bits 0) (font 0)}
[{\em Function}]}
\\ \bf with &
\cltxt
{\clkwd code-char {\em code}
[{\em Function}]}
\editend
\\
\edithead {\csdag 9 (p240)}
\editstart
\\ \bf replace &
\cltxt
All three arguments must be non-negative integers. If it is possible
in the
implementation to construct a character object whose code attribute
is {\em code},
whose
bits attribute is {\em bits}, and whose font attribute is {\em font},
then such an object
is returned;
\\ \bf with &
\cltxt
The argument must be a non-negative integer. If it is possible
in the
implementation to construct a character object identified by
{\em code},
then such an object is returned;
\editend
\\
\edithead {\csdag 10 (p240)}
\editstart
\\ \bf replace &
\cltxt
For any integers, {\em c, b,} and {\em f}, if {\clkwd (code-char
{\em c b f})} is
\\ \bf with &
\cltxt
For any integer, {\em c}, if {\clkwd (code-char
{\em c})} is
\editend
\\
\edithead {\csdag 12 (p240)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd (char-bits (code-char } ...
\editend
\\
\edithead {\csdag 13 (p240)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd (char-font (code-char } ...
\editend
\\
\edithead {\csdag 14 (p240)}
\editstart
\\ \bf delete &
\cltxt
If the font and bits attributes ...
\editend
\\
\edithead {\csdag 15 (p240)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd (char= (code-char (char-code ...}
\editend
\\
\edithead {\csdag 16 (p240)}
\editstart
\\ \bf delete &
\cltxt
is true.
\editend
\\
\edithead {\csdag 17 (p240)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd make-char} ...
\editend
\\
\edithead {\csdag 18 (p240)}
\editstart
\\ \bf delete &
\cltxt
The argument {\em char} must be ...
\editend
\\
\edithead {\csdag 19 (p240)}
\editstart
\\ \bf delete &
\cltxt
If {\em bits} or {\em font} are zero ...
\editend
\\
\edithead {\csdag 19 (p240)}
\editstart
\\ \bf append &
\cltxt
{\clkwd find-char} {\em label registry} [{\em Function}]
\\ &
{\clkwd find-char} returns a character object.
The arguments {\em label} and {\em registry} are names
(objects coerceable to strings as if by the function {\clkwd string})
of character registries and labels.
{\em label}
uniquely identifies a character within the character
registry named {\em registry}.
If the implementation does not support the specified
character, {\clkwd nil} is returned.
\editend
\setcounter{subsection}{3}
\subsection{Character Conversions} % 13.4.
\edithead {\csdag 8 (p241)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd char-upcase} returns a character object with the same
font and bits attributes as {\em char}, but with possibly a
different code attribute.
\\ \bf with &
\cltxt
{\clkwd char-upcase} returns a character object with possibly
a different code.
\editend
\\
\edithead {\csdag 10 (p241)}
\editstart
\\ \bf replace &
\cltxt
Similarly, {\clkwd char-downcase} returns a character object with the
same font and bits attributes as {\em char}, but with possibly a
different code attribute.
\\ \bf with &
\cltxt
Similarly, {\clkwd char-downcase} returns a character object with
possibly a different code.
\editend
\\
\edithead {\csdag 12 (p241)}
\editstart
\\ \bf delete &
\cltxt
Note that the action of ...
\editend
\\
\edithead {\csdag 13 (p241)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd digit-char {\em weight} \&optional ({\em radix} 10)
({\em font} 0) [{\em Function}]}
\\ \bf with &
\cltxt
{\clkwd digit-char {\em weight} \&optional ({\em radix} 10)
[{\em Function}]}
\editend
\\
\edithead {\csdag 14 (p241)}
\editstart
\\ \bf replace &
\cltxt
All arguments must be integers. {\clkwd digit-char} determines
whether or not it is
possible
to construct a character object whose font attribute is {\em font},
and whose {\em code}
\\ \bf with &
\cltxt
All arguments must be integers. {\clkwd digit-char} determines
whether or not it is
possible to construct a character object whose {\em code}
\editend
\\
\edithead {\csdag 15 (p242)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd digit-char} cannot return {\clkwd nil} if {\em font}
is zero, {\em radix}
\\ \bf with &
\cltxt
{\clkwd digit-char} cannot return {\clkwd nil}.
{\em radix}
\editend
\\
\edithead {\csdag 22 (p242)}
\editstart
\\ \bf delete &
\cltxt
Note that no argument is provided for ...
\editend
\\
\edithead {\csdag 23 through 30 (p242, char-int, int-char)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd char-int} {\em char}
\editend
\\
\edithead {\csdag 32 (p242)}
\editstart
\\ \bf replace &
\cltxt
All characters that have zero font and bits attributes and that are
non-graphic
\\ \bf with &
\cltxt
All characters that are
non-graphic
\editend
\\
\edithead {\csdag 33 (p243)}
\editstart
\\ \bf replace &
\cltxt
The standard newline and space characters have the respective
names {\clkwd Newline} and {\clkwd Space}. The semi-standard
characters have the names {\clkwd Tab, Page, Rubout, Linefeed,
Return,} and {\clkwd Backspace}.
\\ \bf with &
\cltxt
The standard newline and space characters have the respective
names {\clkwd Newline} and {\clkwd Space}.
\editend
\\
\edithead {\csdag 35 (p243)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd char-name} will only locate "simple" ...
\editend
\\
\edithead {\csdag 36 (p243)}
\editstart
\\ \bf append &
\cltxt
{\clkwd name-char} may accept other names for characters
in addition to those returned by {\clkwd char-name}.
\editend
\\
\edithead {\csdag 36 (p243)}
\editstart
\\ \bf append &
\cltxt
{\clkwd char-registry-name} {\em char} [{\em Function}]
\\ &
{\clkwd char-registry-name} returns a string representing
the character registry to which {\em char} belongs.
\editend
\\
\edithead {\csdag 36 (p243)}
\editstart
\\ \bf append &
\cltxt
{\clkwd char-label} {\em char} [{\em Function}]
\\ &
{\clkwd char-label} returns a string representing
the character label of {\em char}.
\editend
\\
\edithead {\csdag 36 (p243)}
\editstart
\\ \bf append &
\cltxt
{\clkwd char-ccs-value} {\em char name} [{\em Function}]
\\ &
{\clkwd char-ccs-value} returns the non-negative integer
representing the encoding of the character {\em char} in
The coded character set named by {\em name}.
If the implementation does not support the specified
coded character set, {\clkwd nil} is returned. If the
named coded character set does not contain the character,
{\clkwd nil} is returned.
\editend
\setcounter{subsection}{4}
\subsection{Character Control-Bit Functions} % 13.5.
\edithead {\csdag delete entire section (p243)}
\editstart
\editend
%----------------------------------------------------------------------
\setcounter{section}{13}
\section{Sequences} % 14
%----------------------------------------------------------------------
\setcounter{subsection}{0}
\subsection{Simple Sequence Functions} % 14.1
\edithead {\csdag 21 (p249,make-sequence)}
\editstart
\\ \bf append &
\cltxt
If type {\clkwd string} is specified, the result is
equivalent to {\clkwd make-string}.
\editend
%----------------------------------------------------------------------
\setcounter{section}{17}
\section{Strings} % 18
%----------------------------------------------------------------------
\edithead {\csdag 1 (p299)}
\editstart
\\ \bf replace &
\cltxt
Specifically, the type {\clkwd string} is identical to the type
{\clkwd (vector string-char),}
which in turn is the same as {\clkwd (array string-char (*))}.
\\ \bf with &
\cltxt
Specifically, the type {\clkwd string} is a subtype of
{\clkwd vector}
and consists of vectors specialized by subtypes of {\clkwd character}.
\editend
\setcounter{subsection}{0}
\subsection{String Access} % 18.1.
\edithead {\csdag 4 (p300)}
\editstart
\\ \bf replace &
\cltxt
character object. (This character will necessarily satisfy the
predicate
{\clkwd string-char-p}).
\\ \bf with &
\cltxt
character object.
\editend
\\
\edithead {\csdag 9 (p300)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd setf} may be used with {\clkwd char} to destructively
replace a character within a string.
\\ \bf with &
\cltxt
{\clkwd setf} may be used with {\clkwd char} to destructively
replace a character within a string.
The new character must be of a type which can be stored in the
string; it is an error otherwise.
\editend
\setcounter{subsection}{2}
\subsection{String Construction and Manipulation} % 18.3.
\edithead {\csdag 2 (p302)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd make-string {\em size} \&key :initial-element [{\em Function}]}
\\ \bf with &
\cltxt
{\clkwd make-string {\em size} \&key :initial-element :element-type
[{\em Function}]}
\editend
\\
\edithead {\csdag 3 (p302,make-string)}
\editstart
\\ \bf replace &
\cltxt
This returns a string (in fact a simple string) of length {\em size},
each of whose characters has been initialized to the
{\clkwd :initial-element} argument. If an {\clkwd :initial-element}
argument is not specified, then the string will be initialized
in an implementation-dependent way.
\\ \bf with &
\cltxt
This returns a string of length {\em size},
each of whose characters has been initialized to the
{\clkwd :initial-element} argument. If an {\clkwd :initial-element}
argument is not specified, then the string will be initialized
in an implementation-dependent way.
The {\clkwd :element-type} argument names the type of the elements
of the string; a string is constructed of the most specialized
type that can accommodate elements of the given type.
If {\clkwd :element-type} is omitted, the type
{\clkwd character} is the default.
\editend
\\
\edithead {\csdag 5 (p302,make-string)}
\editstart
\\ \bf replace &
\cltxt
A string is really just a one-dimensional array of "string
characters" (that is,
those characters that are members of type {\clkwd string-char}).
More complex character arrays may be constructed using the function
{\clkwd make-array}.
\\ \bf with &
\cltxt
More complex character arrays may be constructed using the function
{\clkwd make-array}.
\editend
\\
\edithead {\csdag 29 (p304,make-string)}
\editstart
\\ \bf replace &
\cltxt
If {\em x} is a string character (a character of type
{\clkwd string-char}), then
\\ \bf with &
\cltxt
If {\em x} is a character, then
\editend
%----------------------------------------------------------------------
\setcounter{section}{21}
\section{Input/Output} % 22
\setcounter{subsection}{0}
\subsection{Printed Representation of LISP Objects} % 22.1.
\setcounter{subsubsection}{0}
\subsubsection{What the Read Function Accepts} % 22.1.1.
\edithead {\csdag Table 22-1: Standard Character Syntax Types (p336)}
\editstart
\\ \bf delete entry &
\cltxt
{\clkwd <tab>} {\em whitespace}
\\ &
{\clkwd <page>} {\em whitespace}
\\ &
{\clkwd <backspace>} {\em constituent}
\\ &
{\clkwd <return>} {\em whitespace}
\\ &
{\clkwd <rubout>} {\em constituent}
\\ &
{\clkwd <linefeed>} {\em whitespace}
\editend
\setcounter{subsubsection}{1}
\subsubsection{Parsing of Numbers and Symbols} % 22.1.2.
\edithead {\csdag Table 22-3: Standard Constituent Character
Attributes (p340)}
\editstart
\\ \bf delete entry &
\cltxt
{\clkwd <backspace>} {\em illegal}
\\ &
{\clkwd <tab>} {\em illegal}
\\ &
{\clkwd <linefeed>} {\em illegal}
\\ &
{\clkwd <page>} {\em illegal}
\\ &
{\clkwd <return>} {\em illegal}
\\ &
{\clkwd <rubout>} {\em illegal}
\editend
\setcounter{subsubsection}{3}
\subsubsection{Standard Dispatching Macro Character Syntax} % 22.1.4.
\edithead {\csdag Table 22-4: Standard \# Macro Character Syntax (p352)}
\editstart
\\ \bf delete entry &
\cltxt
{\clkwd \#<backspace>} {\em signals error}
\\ &
{\clkwd \#<tab>} {\em signals error}
\\ &
{\clkwd \#<linefeed>} {\em signals error}
\\ &
{\clkwd \#<page>} {\em signals error}
\\ &
{\clkwd \#<return>} {\em signals error}
\\ &
{\clkwd \#<rubout>} {\em undefined}
\editend
\\
\edithead {\csdag 8 (p353)}
\editstart
\\ \bf replace &
\cltxt
The following names are standard across all implementations:
\\ \bf with &
\cltxt
All non-graphic
characters, including extended characters, are uniquely
named in an implementation-dependent manner.
In particular, an implementation may support names of the
form {\em label:registry}.
The following names are standard across all implementations:
\editend
\\
\edithead {\csdag 11 through 18 inclusive delete (p353)}
\editstart
\\ \bf delete &
\cltxt
The following names are semi-standard; ...
\editend
\\
\edithead {\csdag 20 through 26 inclusive delete (p354)}
\editstart
\\ \bf delete &
\cltxt
The following convention is used in implementations ...
\editend
\\
\edithead {\csdag 108 (p360)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd \#<space>, \#<tab>, \#<newline>, \#<page>, \#<return>}
\\ \bf with &
\cltxt
{\clkwd \#<space>, \#<newline>}
\editend
\setcounter{subsubsection}{4}
\subsubsection{The Readtable} % 22.1.5.
\edithead {\csdag 3 (p360)}
\editstart
\\ \bf replace &
\cltxt
Even if an implementation supports characters with non-zero
{\em bits} and {\em font}
attributes, it need not (but may) allow for such characters to
have syntax
descriptions
in the readtable. However, every character of type
{\clkwd string-char}
must be represented in the readtable.
\\ \bf with &
\cltxt
All base and extended characters
are representable in the readtable.
\editend
\setcounter{subsubsection}{5}
\subsubsection{What the Print Function Produces} % 22.1.6.
\edithead {\csdag 13 (p366)}
\editstart
\\ \bf replace &
\cltxt
is used. For example, the printed representation of the character
\#$\backslash$A
with control
and meta bits on would be \#$\backslash${\clkwd CONTROL-META-A},
and that of
\#$\backslash$a with control and meta bits on would be
\#$\backslash${\clkwd CONTROL-META-$\backslash$a}.
\\ \bf with &
\cltxt
is used (see 22.1.4).
\editend
\setcounter{subsection}{2}
\subsection{Output Functions} % 22.3.
\setcounter{subsubsection}{0}
\subsubsection{Output to Character Streams} % 22.3.1.
\edithead {\csdag 26 (p384)}
\editstart
\\ \bf replace &
\cltxt
({\em not} the substring delimited by {\clkwd :start} and
{\clkwd :end}).
\\ \bf with &
({\em not} the substring delimited by {\clkwd :start} and
{\clkwd :end}).
Only characters which are members of the coded character set(s)
associated with the output stream or \#$\backslash${\clkwd Newline}
are valid to be written;
it is an error otherwise. All character streams must provide
appropriate line division behavior for
\#$\backslash${\clkwd Newline}.
\editend
\\
\edithead {\csdag 27 after (p384)}
\editstart
\\ \bf insert &
\cltxt
{\clkwd external-coded-string-length} {\em object} \&{\clkwd optional}
{\em output-stream} [{\em Function}]
\\ &
{\clkwd external-coded-string-length}
returns the number of implementation defined
units required for the object on the output-stream. If
not applicable to the output stream, the function
returns {\clkwd nil}.
This number corresponds to the current state of the stream
and may change if there has been intervening output.
If the output stream is not specified {\clkwd *standard-output*}
is the default.
\editend
\setcounter{subsubsection}{2}
\subsubsection{Formatted Output to Character Streams} % 22.3.3.
\edithead {\csdag 23 delete example (p387)}
\editstart
\\ \bf delete &
\cltxt
{\clkwd (format nil "Type} $\tilde{ }$
{\clkwd :C to $\tilde{ }$ :A."} . . .
\editend
\\
\edithead {\csdag 66 (p389)}
\editstart
\\ \bf replace &
\cltxt
$\tilde{ }${\clkwd :C} spells out the names of the control bits and
represents non-printing
characters by their names: {\clkwd Control-Meta-F, Control-Return,
Space}.
This is a "pretty" format for printing characters.
\\ \bf with &
\cltxt
$\tilde{ }${\clkwd :C}
represents non-printing
characters by their names: {\clkwd Newline,
Space}. This is a "pretty" format
for printing characters.
\editend
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\setcounter{section}{22}
\section{File System Interface} % 23
\setcounter{subsection}{1}
\subsection{Opening and Closing Files} % 23.2.
\edithead {\csdag 2 (p418)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd open {\em filename} \&key :direction :element-type}
{\clkwd :if-exists :if-does-not-exist}
[{\em Function}]
\\ \bf with &
\cltxt
{\clkwd open {\em filename} \&key :direction :element-type}
{\clkwd
:external-coded-character-format}
{\clkwd :if-exists :if-does-not-exist}
[{\em Function}]
\editend
\\
\edithead {\csdag 11 (p419)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd string-char}
\\ &
The unit of transaction is a string-character. The functions
{\clkwd read-char}
and/or {\clkwd write-char} may be used on the stream.
\\ \bf with &
\cltxt
The default value of {\clkwd :element-type} is
implementation-defined as character or a subtype of character.
\\ &
{\clkwd base-character}
\\ &
The unit of transaction is a base character. The functions
{\clkwd read-char}
and/or {\clkwd write-char} may be used on the stream.
\editend
\\
\edithead {\csdag 16 (p419)}
\editstart
\\ \bf replace &
\cltxt
{\clkwd character}
\\ &
The unit of transaction is any character, not just a string-character.
The functions {\clkwd read-char} and/or {\clkwd write-char} may
be used on the stream.
\\ \bf with &
\cltxt
{\clkwd character}
\\ &
The unit of transaction is any character.
The functions {\clkwd read-char} and/or {\clkwd write-char} may
be used on the stream.
\editend
\\
\edithead {\csdag 19 after (p420)}
\editstart
\\ \bf insert &
\cltxt
{\clkwd :external-coded-character-format}
\\ &
This argument specifies a name or list of
names(s) indicating an implementation recognized scheme for
representing 1 or more coded character sets with non-homogeneous codes.
\\ &
The default value is {\clkwd :default} and is
implementation defined but must include the
base characters.
\\ &
As many coded character set names must be provided as the
implementation requires for that external coding convention.
\\ &
References to standard ISO coded character set names must
include the full ISO reference number and approval year.
The following are valid ISO reference names:
:ISO8859/1-1987, :ISO6937/2-1983, :ISO646-1983, etc..
All implementation recognized schemes are formed from
{\clkwd standard-p} characters.
\editend
%----------------------------------------------------------------------
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\begin{thebibliography}{wwwwwwww 99}
\bibitem[Ida87]{ida87} M. Ida, et al.,
{\em
JEIDA Common LISP Committee Proposal on Embedding Multi-Byte Characters
},
ANSI X3J13 document 87-022, (1987).
\bibitem[ISO 646]{iso646} ISO,
{\em
Information processing -- ISO 7-bit coded character set
for information interchange
},
ISO (1983).
\bibitem[ISO 4873]{iso4873} ISO,
{\em
Information processing -- ISO 8-bit code for information
interchange -- Structure and rules for implementation
},
ISO (1986).
\bibitem[ISO 6937/1]{iso6937/1} ISO,
{\em
Information processing -- Coded character sets for text
communication -- Part 1: General introduction
},
ISO (1983).
\bibitem[ISO 6937/2]{iso6937/2} ISO,
{\em
Information processing -- Coded character sets for text
communication -- Part 2: Latin alphabetic and non-alphabetic
graphic characters
},
ISO (1983).
\bibitem[ISO 8859/1]{iso8859/1} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 1: Latin alphabet No. 1
},
ISO (1987).
\bibitem[ISO 8859/2]{iso8859/2} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 2: Latin alphabet No. 2
},
ISO (1987).
\bibitem[ISO 8859/6]{iso8859/6} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 6: Latin/Arabic alphabet
},
ISO (1987).
\bibitem[ISO 8859/7]{iso8859/7} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 7: Latin/Greek alphabet
},
ISO (1987).
\bibitem[Kerns87]{kerns87} R. Kerns,
{\em
Extended Characters in Common LISP
},
X3J13 Character Subcommittee document, Symbolics Inc (1987).
\bibitem[Kurokawa88]{kurokawa88} T. Kurokawa, et al.,
{\em
Technical Issues on International Character Set Handling in Lisp
},
ISO/IEC SC22 WG16 document N33, (1988).
\bibitem[Linden87]{linden87} T. Linden,
{\em
Common LISP - Proposed Extensions for International Character Set
Handling
},
Version 01.11.87, IBM Corporation (1987).
\bibitem[Steele84]{steele84} G. Steele Jr.,
{\em
Common LISP: the Language
},
Digital Press (1984).
\bibitem[Xerox87]{xerox87} Xerox,
{\em
Character Code Standard, Xerox System Integration Standard
},
Xerox Corp. (1987).
\end{thebibliography}
\end{document} % End of document.
∂22-Feb-89 1432 @Score.Stanford.EDU:gio@sumex-aim.stanford.edu A Proposal to Change Initial Student Support
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Feb 89 14:32:19 PST
Received: from sumex-aim.stanford.edu by SCORE.STANFORD.EDU with TCP; Wed 22 Feb 89 14:30:14-PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA03716; Wed, 22 Feb 89 14:29:43 PST
Date: Wed, 22 Feb 1989 14:29:42 PST
From: Gio Wiederhold <gio@sumex-aim.stanford.edu>
To: faculty@score.stanford.edu
Subject: A Proposal to Change Initial Student Support
Message-Id: <CMM.0.88.604189782.gio@sumex-aim.stanford.edu>
We complain that students who are not immediatly involved in research loose
time and contact, but we are supporting <some/many> of our students during
their initial year directly. I propose a change in the way this policy is
implemented.
1. The department will make funds available to support students in their
first quarter here, and if desirable for more quarters during their
first year.
2. The funds are made available to faculty, and perhaps research associates
to support first year students they wish to advise. A minimal notification
is sufficient to obtain such funds for the first quarter. All new students,
however, if they wish to be supported by the department, must search out
an advisor.
3. For support in successive quarter, a more formal note may be needed,
although it should still <perhaps> be less painful for the faculty member
than going out and getting the $5000.- of external research funding that a
quarter of a student's support represents.
Your's for change --- I guess I consider changes in themselves useful and
interesting. Stability is dull.
Gio
∂22-Feb-89 1515 HEMENWAY@Score.Stanford.EDU Super-stars
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Feb 89 15:15:37 PST
Date: Wed 22 Feb 89 15:15:00-PST
From: Sharon Hemenway <HEMENWAY@Score.Stanford.EDU>
Subject: Super-stars
To: phd-adm@Score.Stanford.EDU
Reply-To: Hemenway@Score.Stanford.EDU
Message-ID: <12472803329.21.HEMENWAY@Score.Stanford.EDU>
If in the course of reading the Round 2 folders, you come across
someone who is clearly a "super-star", absolute-no-doubt-admittee,
please let either Mike or me know. We'll pull the folder and if the
over-whelming concensus of the readers is definitely to admit him/her,
we'll take early action. I am assuming that the very few people this
might apply to will probably be those who were marked Early Admit in
Round 1 but only had 1 or 2 readings.
thanks--
Sharon
-------
∂22-Feb-89 1545 hyde@csli.Stanford.EDU CSLI Calendar, Feb 23, 4:17
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Feb 89 15:45:41 PST
Received: by csli.Stanford.EDU (4.0/inc-1.0)
id AA29377; Wed, 22 Feb 89 15:09:08 PST
Date: Wed, 22 Feb 89 15:09:08 PST
From: hyde@csli.Stanford.EDU (Dawn Hyde)
Message-Id: <8902222309.AA29377@csli.Stanford.EDU>
To: friends@csli.Stanford.EDU
Subject: CSLI Calendar, Feb 23, 4:17
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
23 February 1989 Stanford Vol. 4, No. 17
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
The Historical Linguistic talk, featuring Dr. Vjacheslav V. Ivanov, has
been postponed until later this spring, time and date to be announced.
____________
SYMBOLIC SYSTEMS FORUM
Turing's Oracle
Solomon Feferman
Department of Mathematics
Friday, 24 February, 3:15
Room 60:61G
This is the curious tale of a powerful and Protean idea. In the
beginning there was Alan Turing's theory of mechanical computability.
Then Turing introduced his idea of computability by means of an
"oracle," but he never did anything with it. Next, Emil Post took it
up as the basis for his theory of degrees of unsolvability. Then came
generalized recursion theory and even more generalized degrees of
unsolvability. All of which has nothing to do with actual
computability, right? Wrong, in my view.
____________
LINGUISTICS DEPARTMENT COLLOQUIUM
Cross-Linguistic Properties
of Anaphoric Systems
Peter Sells
Department of Linguistics
Friday, 24 February, 3:30
Cordura Hall Conference Room
In the past few years there has been a considerable amount of work done
investigating systems of anaphora involving pronouns and reflexives,
in many different languages. In this paper I would like to review
some of this work, and make some observations about where it leaves us
and what it suggests for future research, concentrating in particular
on the relation between syntactic, semantic, and discourse-based
aspects of anaphora.
____________
COMMONSENSE AND NONMONOTONIC REASONING SEMINAR
Algebraic Techniques
in Boolean Constraint Satisfaction
Peter Ladkin
Kestrel Institute
Monday, 27 February, 3:15
MJH 301
Many techniques used for binary Boolean Constraint Satisfaction Problems
(CSPs) may be formulated in terms of the operations in an algebra of
relations, originally due to Tarski in 1941, but ultimately going back
to Peirce and Schroeder last century. I shall introduce the
relation-algebraic vocabulary, and present some reasonable subset of
the following results. Path-consistency has been suggested as a
heuristic for satisfaction (often NP-complete). Path-consistency
computations may be accomplished in n-squared log n time in parallel,
and there is also a lower bound for reduction-type algorithms (serial
or parallel) of n-squared time (using a concocted class of examples).
We shall also give naturally occurring examples of classes of CSPs
with n-squared satisfaction algorithms for path-consistent networks,
including a large subclass of Allen's temporal reasoning problems; and
classes in which even atomically labelled path-consistent networks are
not satisfiable. (This is joint work with Roger Maddux).
____________
SYMBOLIC SYSTEMS FORUM
A Computational Psychological Approach
to Commonsense Perception
Dr. Jeffry Shrager
Friday, 3 March, 3:15
Room 60:61G
Commonsense perception is a generalized version of what Dretske has
called "epistemic seeing"--that is, a knowledge-based interpretation of
(perceptual) experience. In this talk I will outline a psychological
approach to the study of commonsense perception in incremental concept
learning. My goal is a computational framework and model whose
processing cycle is knowledge revision by commonsense perception, and
which subsumes rule-based inference, perceptual reasoning, and most
inductive and instructed learning tasks.
____________
LINGUISTICS DEPARTMENT COLLOQUIUM
A Creolist's View
Lawrence Carrington
University of the West Indies
and Stanford University
Friday, 3 March, 3:15
Cordura Conference Room
____________
∂22-Feb-89 1630 X3J13-mailer cs proposal part 3 of 3
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Feb 89 16:30:21 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 543952; Wed 22-Feb-89 19:27:07 EST
Date: Wed, 22 Feb 89 19:27 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: cs proposal part 3 of 3
To: Thom Linden <baggins@IBM.com>
cc: Common Lisp mailing <x3j13@SAIL.STANFORD.EDU>
In-Reply-To: <890222.100851.baggins@almvma>
Message-ID: <19890223002701.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
The last time you mailed this out it was only with great difficulty
and a lot of help from my friends that I was able to read it. The
version of LaTex available to me blows out when your document is
run through it. If you (or anyone else on this list) has a DVI
file already in a publicly (FTP) accessible place, I'd appreciate
knowing about it. Probably other recipients are in the same boat,
so mail the file name to X3J13.
∂22-Feb-89 1633 @Score.Stanford.EDU:katiyar@polya.Stanford.EDU WINTER POTLUCK REMINDER
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Feb 89 16:33:11 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 22 Feb 89 16:23:19-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA27454; Wed, 22 Feb 89 16:21:43 -0800
Date: Wed, 22 Feb 1989 16:21:42 PST
Sender: "Dinesh H. Katiyar" <katiyar@polya.stanford.edu>
From: Social Committee <katiyar@polya.stanford.edu>
To: faculty@score, research-associates@score, secretaries@score,
students@score
Subject: WINTER POTLUCK REMINDER
Message-Id: <CMM.0.87.604196502.katiyar@polya.stanford.edu>
*************************************************************************
********************* 1989 WINTER QUARTER POTLUCK **********************
*************************************************************************
This is to remind you about the CSD potluck that shall be held at
Prof. Vaughan Pratt's place at noon on Sunday, the 26th of Feb.
This is a great opportunity for the *entire* department to get
together. All faculty, staff, and students (Ph.D., Masters,
and Undergrads) and their guests are invited.
If you intend to come to the potluck, then please run the program
~katiyar/food on Polya to sign up. If you don't have an account
on Polya, send mail to one of the members of the social committee.
We hope to see you there!
-------------------------------------------------------------------------
Student Social Committee
------------------------
jennifer anderson jaikumar ramanathan dinesh katiyar
anderson@polya jaikumar@polya katiyar@polya
-------------------------------------------------------------------------
......................................................
: Dinesh Katiyar : Apartment 16Y :
: Ph.D. student : Rains Houses Box 321 :
: Computer Science : Stanford,CA 94305 :
: Stanford University : ph:415-323-7911 :
:..........................:.........................:
∂22-Feb-89 1707 X3J13-mailer Re: cs proposal part 3 of 3
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 22 Feb 89 17:07:40 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA01715; Wed, 22 Feb 89 18:04:48 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA09867; Wed, 22 Feb 89 18:04:43 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8902230104.AA09867@defun.utah.edu>
Date: Wed, 22 Feb 89 18:04:42 MST
Subject: Re: cs proposal part 3 of 3
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Thom Linden <baggins@IBM.com>,
Common Lisp mailing <x3j13@SAIL.STANFORD.EDU>
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Wed, 22 Feb 89 19:27 EST
There is a copy of the DVI file on cs.utah.edu (128.110.4.21). The
file is pub/cl-cs-proposal.dvi.
-Sandra
-------
∂22-Feb-89 1713 X3J13-mailer cs proposal straw vote
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 22 Feb 89 17:12:50 PST
Date: Wed, 22 Feb 89 12:08:15 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890222.120815.baggins@almvma>
Subject: cs proposal straw vote
I would like to take a straw vote on various components of
the Characters proposal. The primary intent is to resolve the
actual list of items to be voted upon at the March meeting.
Let me know if you think some items should be separated or
combined. The vote may also indicate which items are controversial
or need revision before the March meeting.
As it is a straw vote, anyone can respond. Please comment on
your vote as well. In particular, if you are voting against
some item I would like to know what change(s), if any,
incorporated into the proposal might reverse your vote.
Issue: CHAR-FONT-UNUSED-CHAR-BITS-NONPORTABLE
Problem: CHAR-FONT isn't used, CHAR-BITS isn't portable.
Proposal:
Eliminate of font and bit attributes.
Add rules for an implementation supporting attributes.
Redefine STRING-CHAR as implementation defined.
Remove CHAR-FONT-LIMIT
Remove CHAR-BITS-LIMIT
Remove INT-CHAR
Remove CHAR-BITS
Remove CHAR-FONT
Remove MAKE-CHAR
Remove CHAR-CONTROL-BIT
Remove CHAR-META-BIT
Remove CHAR-SUPER-BIT
Remove CHAR-HYPER-BIT
Remove CHAR-BIT
Remove SET-CHAR-BIT
Issue: CHAR-INT-ONLY-USEFUL-WHEN-ATTRIBUTES-SUPPORTED
Problem: CHAR-INT behavior is CHAR-CODE unless implementation
defined attributes are supported.
Proposal:
Remove CHAR-INT
Issue: CHARACTER-TYPE-RESTRICTIVEC
Problem: CHARACTER type doesn't allow thin & fat characters.
Proposal: a
Define BASE-CHARACTER as a subtype of STRING. a
Standard characters are a subset of the base
characters.
STANDARD-CHAR type is replaced by (CHARACTER :STANDARD)
Remove the semi-standard characters.
Issue: STRING-TYPE-RESTRICTIVE
Problem: STRING type doesn't allow thin & fat strings.
Proposal: a
Define STRING as a union type a
STRING used as a type specifier for object creation
means (VECTOR CHARACTER)
All string functions operate as specified on any a
string object except it is an error to insert
an extended character into a base string.
Extend the COERCE function to allow coercion from a
base string to extended string.
Issue: STRING-TYPE-ABBREVIATIONS
Problem: new types are awkward to name, want abbreviations.
Proposal: ne
Add BASE-STRING
Add GENERAL-STRING
Issue: SIMPLE-STRING-TYPE-RESTRICTIVE
Problem: SIMPLE STRING type doesn't allow thin & fat strings.
Proposal: a
Define SIMPLE-STRING as a union type a
Define SIMPLE-STRING as a type specifier for object
creation means (SIMPLE-ARRAY CHARACTER (size))
Issue: SIMPLE-STRING-TYPE-ABBREVIATIONS
Problem: new types are awkward to name, want abbreviations.
Proposal: ne
Add SIMPLE-BASE-STRING
Add SIMPLE-GENERAL-STRING
Issue: FILE-EXTERNAL-REPRESENTATION
Problem: can't specify external encoding even when there are lots
Proposal:
Add :EXTERNAL-CODED-CHARACTER-FORMAT keyword to OPEN
Issue: STRING-BINARY-WIDTH
Problem: Can't find out how many bytes a string will take when written as
text
Proposal:
Add :EXTERNAL-CODED-STRING-LENGTH function
Issue: CHAR-CODE-NON-PORTABLE
Problem: no way to talk about well-known external coding methods, only
internal codes
Proposal:
Add CHAR-CCS-VALUE function
Issue: CHARACTER-IDENTIFICATION-NONPORTABLE
Problem: Can't portably talk about non-standard characters
Proposal:
Introduce the concept of Registries
Standardize on #\registry:id, add all-implemented-registries
Add *ALL-CHARACTER-REGISTRY-NAMES* variable
Add FIND-CHAR function
Add CHAR-LABEL function
Add CHAR-REGISTRY-NAME function
New syntax for CHARACTER type specifier
New #\label:registry character name syntax
New argument to CHARACTERP
∂22-Feb-89 1714 X3J13-mailer cs proposal
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 22 Feb 89 17:13:58 PST
Date: Wed, 22 Feb 89 12:41:41 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890222.124141.baggins@almvma>
Subject: cs proposal
I'm also mailing everyone (in Mathis mailing labels) a hardcopy
which is dated 22 Feb and contains the errata change to page 25.
Regards,
Thom
∂22-Feb-89 1713 X3J13-mailer cs proposal errata
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 22 Feb 89 17:13:33 PST
Date: Wed, 22 Feb 89 12:22:03 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890222.122203.baggins@almvma>
Subject: cs proposal errata
Page 25, the insertion "23 after (p49):
(GENERAL-STRING size)
Means the same as (ARRAY CHARACTER (size)): the set of base
strings of the indicated size.
(SIMPLE-GENERAL-STRING size)
Means the same as (SIMPLE-ARRAY GENERAL-CHARACTER (size)): the
set of simple general strings of the indicated size.
Should read:
(GENERAL-STRING size)
Means the same as (ARRAY CHARACTER (size)): the set of general
strings of the indicated size.
(SIMPLE-GENERAL-STRING size)
Means the same as (SIMPLE-ARRAY CHARACTER (size)): the set of
simple general strings of the indicated size.
∂23-Feb-89 0029 @Score.Stanford.EDU:cheriton@Pescadero.Stanford.EDU Re: A Proposal to Change Initial Student Support
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Feb 89 00:28:59 PST
Received: from Pescadero.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 23 Feb 89 00:27:41-PST
Received: by Pescadero.Stanford.EDU (5.59/25-eef) id AA13147; Thu, 23 Feb 89 00:26:03 PDT
Date: Thu, 23 Feb 89 00:26:03 PDT
From: David Cheriton <cheriton@Pescadero.Stanford.EDU>
Message-Id: <8902230826.AA13147@Pescadero.Stanford.EDU>
To: faculty@score.stanford.edu, gio@sumex-aim.stanford.edu
Subject: Re: A Proposal to Change Initial Student Support
In-Reply-To: <CMM.0.88.604189782.gio@sumex-aim.stanford.edu> from Gio
Wiederhold <gio@sumex-aim.stanford.edu> on Wed, 22 Feb 1989 14:29:42
PST
I presume an unspoken part of your proposal is that faculty with research
funds would be discriminated against in getting dept. funds.
I think our current scheme is better, frankly, if we tighten it up and
basically communicate to the students that the first year dept support
is to pass the comps and find a research advisor and get support.
No student gets dept support in year 2 or later. I think that would be
a strong incentive for students to get 1st year things accomplished in
first year, and that's OK by me.
My impression is that the dept has continued to support some students
beyond year 1 if they didnt manage to find other support. Please someone
correct me if I'm wrong.
∂23-Feb-89 0318 @Score.Stanford.EDU:ARK@SAIL.Stanford.EDU Re: A Proposal to Change Initial Student Support
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Feb 89 03:18:35 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 23 Feb 89 03:17:26-PST
Message-ID: <s4Rhc@SAIL.Stanford.EDU>
Date: 23 Feb 89 0317 PST
From: Arthur Keller <ARK@SAIL.Stanford.EDU>
Subject: Re: A Proposal to Change Initial Student Support
To: cheriton@PESCADERO.STANFORD.EDU, faculty@SCORE.STANFORD.EDU,
gio@SUMEX-AIM.STANFORD.EDU
I'm wondering how all this affects fellowship students, or the distinction
between fellowship students and non-fellowship students. What percentage
of our entering PhD students have fellowships these days?
Arthur
∂23-Feb-89 1143 @Score.Stanford.EDU:winograd@loire.stanford.edu Undergraduate committee meeting next Wed, March 1, 4:30pm
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Feb 89 11:43:42 PST
Received: from loire.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 23 Feb 89 11:37:47-PST
Received: by loire.stanford.edu (5.59/25-eef) id AA02217; Thu, 23 Feb 89 11:36:02 PDT
Date: Thu, 23 Feb 89 11:36:02 PDT
Message-Id: <8902231936.AA02217@loire.stanford.edu>
From: Terry Winograd <Winograd@csli.stanford.edu>
To: ugc@score
Subject: Undergraduate committee meeting next Wed, March 1, 4:30pm
Cc: ac@score, g.gorin@macbeth, reid@wrl.dec.com
There will be a meeting of the undergraduate committee NEXT WEDNESDAY,
MARCH 1, FROM 4:30PM TO 6PM, in MJH 352, to discuss the following issues:
1) The listing of the program for next year's courses and degrees. I
will make available the current version to the committee (it is also in
the book). Any changes need to be made by next week. I don't see any
major issues here (except the one raised in the next item), but we
should check it over and make any changes we find necessary.
2) Core curriculum. There has been a lot of discussion about the
organization of the 106:109 sequence, and it has been discussed in the
curriculum committee. Various people have strong feelings, including
Roy Jones and Bob Floyd. I would hope to include Leo Guibas (chair of
the curriculum committee) in the discussion as well. We might also get
useful input from Gorin and Reid since they are now teaching 109 and we
need to deal with its future. I will send out a more detailed
background discussion before the meeting. Someone (either us in this
meeting or Leo in one of his) needs to make a firm decision on these
issues so courses and faculty can be scheduled for next year and
appropriate descriptions can go into courses and degrees. This is the
main action topic for the meeting.
3) Overall undergraduate curriculum. At the moment, there are very few
courses beyond the core aimed at undergraduates. They jump into
courses directed to the Masters students, with mixed results. At this
meeting I want to introduce the issue and solicit suggestions as to
what we might do in the future to improve the situation.
4) Advising. Advising is a hit or miss proposition at the moment, with
some staff putting in great deal of personal effort with some of our
students, while other students never see an advisor. Maybe this is OK,
or maybe we want to institute more structure (e.g., requiring that
study lists be signed) or redistribute the load. I sent out a
discussion on this a while back (I will resend to anyone who wants),
and wanted to generate ideas on actions that might help.
5) Getting students more connected to the department and research. A
number of ideas have been suggested and we should review them and see
if people can take on activities to address this.
6) Report on hiring - I will find out from Nils the status of the
effort to get a professor(teaching) slot for the associate chair, and
the status with Mike Clancy. Roy can report on lecturer hiring. No
action items here as far as I know.
This list is long, and we are scheduled for an hour and a half. We may
need to put off some of the topics for another meeting if we don't get
to them. I will be pushing to keep discussions brief and to the point,
so maybe we'll be able to do it.
--t
∂23-Feb-89 1212 @Score.Stanford.EDU:gio@sumex-aim.stanford.edu Re: A Proposal to Change Initial Student Support
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Feb 89 12:12:20 PST
Received: from sumex-aim.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 23 Feb 89 12:10:38-PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA25346; Thu, 23 Feb 89 12:10:05 PST
Date: Thu, 23 Feb 1989 12:10:05 PST
From: Gio Wiederhold <gio@sumex-aim.stanford.edu>
To: David Cheriton <cheriton@pescadero.stanford.edu>
Cc: faculty@score.stanford.edu, gio@sumex-aim.stanford.edu
Subject: Re: A Proposal to Change Initial Student Support
In-Reply-To: Your message of Thu, 23 Feb 89 00:26:03 PDT
Message-Id: <CMM.0.88.604267805.gio@sumex-aim.stanford.edu>
Your message does not address my objective -- improving faculty to student
linkage.
It was not my intent to discriminate against myself. I typically have
supported students ab initio, some of them stayed, some of them went on to
other projects and faculty but that's ok.
However, if some incoming students are to be supported for a year solely
to pass the comps then I am either not being fair to my students, if
I expect some research participation, or to my funders, for wasting their
money. Gio
∂23-Feb-89 1251 @Score.Stanford.EDU:JMC@SAIL.Stanford.EDU
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Feb 89 12:51:11 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 23 Feb 89 12:49:37-PST
Message-ID: <194wAU@SAIL.Stanford.EDU>
Date: 23 Feb 89 1249 PST
From: John McCarthy <JMC@SAIL.Stanford.EDU>
To: faculty@Score.Stanford.EDU
I plan to release our resolution on rhf to Daily, etc. tonight.
∂23-Feb-89 1452 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu [AS.BTH@Forsythe.Stanford.EDU: AFOSR URI BAA]
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Feb 89 14:52:09 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 23 Feb 89 14:49:21-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA10086; Thu, 23 Feb 89 14:46:15 PDT
Date: Thu, 23 Feb 89 14:46:15 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8902232246.AA10086@Tenaya.stanford.edu>
To: faculty@score
Subject: [AS.BTH@Forsythe.Stanford.EDU: AFOSR URI BAA]
fyi:
----
Return-Path: <@Tenaya.stanford.edu,@Score.Stanford.EDU:AS.BTH@Forsythe.Stanford.EDU>
Date: Thu, 23 Feb 89 11:20:13 PST
To: nilsson@score
From: AS.BTH@Forsythe.Stanford.EDU
Subject: AFOSR URI BAA
TO: Distribution
FROM: Bonnie Hale, SPO
SUBJECT: AFOSR BROAD AGENCY ANNOUNCEMENT: UNIVERSITY RESEARCH INIT
It was finally published in the CBD!
COMMERCE BUSINESS DAILY PUBLICATION DATE: FEBRUARY 22, 1989
BROAD AGENCY ANNOUNCEMENT (BAA): BASIC RESEARCH IN SUPPORT OF THE
AIR FORCE DEFENSE RESEARCH SCIENCES PROGRAM POC L Harrison,
202/767-4943, Chief, Support Services Div, Directorate of Contracts.
This is a special Broad Agency Announcement (BAA) issued by the Air
Force Office of Scientific Research (AFOSR) in support of the Air
Force University Research Initiative (URI) FY 1990 Program. Because
of the special nature and unique objectives of the program only
universities and colleges with capabilities for research and
teaching will be considered for the program. Continued support of
the Air Force University Research Initiative Program is currently
under consideration by the U.S. Congress; however, funds for FY 90
have not been appropriated and funding of the program is contingent
upon this appropriation. Accordingly, offerors are advised that
proposals submitted in response to this BAA will be considered only
if such funding is made avail for AFOSR. Proposals will be
considered in response to the following broad areas of science and
engineering research. It is essential that proposers, as they
develop their proposals, contact one or more of the following AFOSR
Program Managers to explore mutual interests in their respective
discipline areas. In this respect, proposers can obtain add'l info
by referring to a brochure issued by AFOSR entitled ""Research
Interests of the Air Force Office of Scientific Research'', Aug 88.
Copies can be obtained by sending a self-addressed label with your
request to: AFOSR/PKO, Bldg 410, Bolling AFB, DC 20332-6448.
Proposals should offer significant advancement in the state of the
art and show evidence of potential contribution to the research
effort. 1. Aerospace Sciences, e.g., Structural Mechanics, Dr
Anthony Amos, 202/767-4937; Structural Durability, Lt Col George K
Haritos, 202/767-0463; Civil Engineering - Geomechanics, Structural
Dynamics, and Matls, Dr Spencer T. Wu, 202/767-6962, and Major
Steve Boyce, 202/767-6963; External Aerodynamics, Dr Len Sakell,
202/767-4935; Internal Fluid Dynamics, Capt Hank E. Helin,
202/767-0471; Turbulence Structure & Control, Dr James M.
McMichael, 202/767-4936; Unsteady & Separated Flows, Capt Hank E.
Helin, 202/767-0471; Air-Breathing Combustion, Dr Julian M.
Tishkoff, 202/767-0465; Rocket and Space Propulsion, Dr Mitat A.
Birkan, 202/767-4938; Diagnostics in Reacting Media, Dr Julian M
Tishkoff, 202/767-0465. 2. Chemical and Atmospheric Sciences,
e.g., Advanced Electrical & Structural Polymers, Dr Donald Ulrich,
202/767-4963; Surface Reactions, in the Space Environment, Lt Col
Larry Burgraff, 202/767-4960; Theory & Analysis of the Geo-Plasma
Environment, Lt Col James Stobie, 202/767-4960. 3. Electronic &
Material Sciences, e.g., Physical Electronics, Dr Gerald L Witt & Dr
Cole Litton, 202/767-4931; Selective Area Heteroepitaxy, Dr Gerald L
Witt, 202/767-4931; Optical Computing & Processing, Dr C Lee Giles,
202/767-4931; Thin Film Sciences, Dr Howard Schlossberg,
202/767-4906; Metallic Structural Materials, Dr Alan H Rosenstein,
202/767-4933; Nonmetallic Structural Materials, Dr Liselotte J
Schioler, 202/767-4933. 4. Life Sciences, e.g., Neuroscience, Dr
William O Berry, 202/767-5021; Visual Perception, Auditory Pattern
Recognition & Spatial Orientation, Dr John F Tangney, 202/767-5021;
Cognition, Dr Alfred R Fregly, 202/767-5021; Toxicology: Health
Effects and Environmental Effects, Major T Jan Cerveny,
202/767-5021. 5. Mathematical & Information Sciences, e.g.,
Mathematical Modeling, Analysis and Computation, Arje Nachman,
202/767-5028; Discrete Mathematics, Dr Neal Glassman, 202/767-5027;
Distributed Parameter Control, Dr Arje Nachman, 202/767-5028;
Parallel Programming, Col Dave Nelson, 202/767-5026. 6. Physical
and Geophysical Sciences, e.g., Extreme Ultraviolet and Soft X-Ray
Free Electron Lasers, Enhanced Synchrotron, Radiation, and Optics,
Dr Howard Schlossberg, 202/767-4906; Recurrent Solar Activity and
the Solar Cycle, Dr Henry R Radoski, 202/767-4906. Evaluation
Factors: Proposals will be evaluated through a peer or scientific
review process and selected for award on a competitive basis
according to Public Law 98-369, Competition in Contracting Act
(1984). 1. The primary evaluation factors are: A. The scientific
and technical merits of the proposed research. B. The potential
contributions of the proposed research to the mission of the Air
Force. C. Availability of funds. 2. Other evaluation criteria
include: A. The likelihood of the proposed effort to develop new
research capabilities and to broaden the university research base in
support of nat'l defense. B. The offeror's capabilities, related
experience, facilities or techniques or unique combinations of these
factors that are integral to achieving the objectives. C. The
qualifications, capabilities, experience, and past research
accomplishments of the proposed Principal Investigator, team leader
or key personnel who are critical to the DOD mission. D. Realism &
reasonableness of proposed cost. E. Offerors record of past
research accomplishments. It is anticipated that this URI program
will cover a period of 3 yrs beginning in FY 90 depending on
Congressional funding. Awards may be made for periods ranging from
one to 3 yrs. Separate cost proposal for FY90, FY91, an FY92 must
be prepared to ensure continuity of the program in the event funds
are available. Proposals shall be prepared IAW the ""Proposer's
Guide to the AFOSR Research Program,'' Dec 86. Copies can be
obtained by sending a self-addressed label with your request to:
AFOSR/PKO, Bolling AFB, DC 20332-6448. Proposers are cautioned to
follow the guidelines of the brochure since any deviations from
those guidelines may render the proposal ineligible. Each proposal
must be clearly marked on the outside of the package identifying it
as a proposal for the University Research Initiative Program
submitted in response to this BAA (BAA No. 89-2). 20 copies of the
proposal will be req'd. The cost of preparing proposals in response
to this announcement is not considered an allowable direct charge to
any resulting grant or contract. It is, however, an allowable
expense to the normal bid and proposal indirect cost specified in
OMB Circular A-21, Cost Principles for Educational Institutions.
Every effort will be made to protect the confidentiality of the
proposal and of any evaluations. The submitter may mark the
proposal with a legend IAW the Federal Acquisition Regulation 52.
215-12 (modified to permit contract evaluations). Proposals must be
submitted in a hard copy and should not exceed 50 pages total.
Unnecessarily elaborate brochures or presentations beyond that
sufficient to present a complete and effective proposal are not
desired. Only contracting officers are legally authorized to commit
the Govt. PROPOSALS IN THE FORMAT DESCRIBED IN THE PROPOSER'S
GUIDE, MUST BE RECEIVED NOT LATER THAN 3:00 p.m. EST on FRIDAY,
APRIL 14 1989, at the address given below. Proposals rec'd at the
specified location after this time and date will be late and will
not be considered for award under this sol. All information on the
preparation & submission of proposals including technical and
financial content can be found in the Proposer's Guide. (048)
SPONSOR: Air Force Office of Scientific Research, Bldg 410, Attn:
XOT (Rm A115), Bolling AFB, DC 20332-6448
To: AS.CFB
cc: OS&AS(AS.VGS,AS.VGM,AS.SKG,AS.RMK,AS.RCB,AS.PHU,AS.PAW,AS.NON,AS.LAR,
AS.LAP,AS.LAB,AS.KAT,AS.GUS,AS.EDR,AS.CMS,AS.CFB,AS.BLP,AS.ACC),
CR.RLB, HF.KXM, HK.PLD, ENGNR(AS.KCC,AS.PMC,HF.JJC,HF.KXM,HF.RRK,
NA.AMC,NA.KHW,BSCOTT@SCORE,CANNON@SIERRA,GOODMAN@SIERRA,
HAGSTROM@SIERRA,HAUSMAN@SIERRA,HOMSY@SIERRA,IGLEHART@SIERRA,
JEZUKEWICZ@SIERRA,KRUGER@SIERRA,LEVINTHAL@SIERRA,LUENBERGER@SIERRA,
NILSSON@SCORE,PALMER@ACROPOLIS,SHAH@SIERRA)
∂23-Feb-89 1620 @polya.Stanford.EDU:tah@linz MTC Seminar
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Feb 89 16:20:53 PST
Received: from linz.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA28180; Thu, 23 Feb 89 16:15:31 -0800
Received: by linz.stanford.edu (5.59/25-eef) id AA03405; Thu, 23 Feb 89 16:15:23 PDT
Message-Id: <8902240015.AA03405@linz.stanford.edu>
To: lop@polya
Subject: MTC Seminar
Date: 23 Feb 89 16:15:20 PST (Thu)
From: Tom Henzinger <tah@linz>
Friday Feb. 24, noon, MJH 301:
Ian Mason (Stanford) will report on joint work with Carolyn Talcott:
> In this talk we present a formal system for
> proving constrained operational equivalence
> between programs with side effects.
∂23-Feb-89 2027 @polya.Stanford.EDU:plotkin@goblin.Stanford.EDU Next AFLB - Tuesday, February 28, 4:15pm.
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 23 Feb 89 20:27:51 PST
Received: from Goblin.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA11516; Thu, 23 Feb 89 20:24:47 -0800
Received: by goblin.Stanford.EDU (5.51/inc-1.0)
id AA03447; Thu, 23 Feb 89 20:24:15 PST
Date: Thu, 23 Feb 89 20:24:15 PST
From: plotkin@goblin.Stanford.EDU (Serge Plotkin )
Message-Id: <8902240424.AA03447@goblin.Stanford.EDU>
To: aflb-all@polya.stanford.edu
Subject: Next AFLB - Tuesday, February 28, 4:15pm.
Next AFLB will be Tuesday, February 28, 4:15pm
in the usual room.
Following is the abstract of my talk:
SUBLINEAR-TIME PARALLEL ALGORITHMS FOR MATCHING AND RELATED PROBLEMS
Serge Plotkin
We present the first sublinear-time deterministic parallel algorithms for
bipartite matching and several related problems, including maximal
node-disjoint paths, depth-first search, and flows in zero-one networks. Our
results are based on a better understanding of the combinatorial structure of
the above problems, which leads to new algorithmic techniques. In particular,
we show how to use maximal matching to extend, in parallel, a current set of
node-disjoint paths and how to take advantage of the parallelism that arises
when a large number of nodes are ``active'' during an execution of a
push/relabel network flow algorithm.
We also show how to apply our techniques to design parallel algorithms for the
weighted versions of the above problems. In particular, we present
sublinear-time deterministic parallel algorithms for finding a minimum-weight
bipartite matching and for finding a minimum-cost flow in a network with
zero-one capacities, if the weights are polynomially bounded integers.
Joint work with A. Goldberg and P. Vaidya.
∂24-Feb-89 0829 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Next Week's Faculty Lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 89 08:29:44 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 24 Feb 89 08:28:23-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA27377; Fri, 24 Feb 89 08:26:50 -0800
Date: Fri, 24 Feb 1989 8:26:45 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score
Cc: bureaucrats@score
Subject: Next Week's Faculty Lunch
Message-Id: <CMM.0.87.604340805.chandler@polya.stanford.edu>
Please mark your calendars for next weeks faculty lunch, Tuesday, 2/28.
Steve Jobs of NeXT will be our visitor.
∂24-Feb-89 1033 @Score.Stanford.EDU:pratt@chehalis.stanford.edu CSD potluck this Sunday
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 89 10:33:10 PST
Received: from chehalis.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 24 Feb 89 10:29:52-PST
Received: by chehalis.stanford.edu (5.59/25-eef) id AA02009; Fri, 24 Feb 89 10:28:36 PDT
Date: Fri, 24 Feb 89 10:28:36 PDT
From: Vaughan Pratt <pratt@chehalis.stanford.edu>
Message-Id: <8902241828.AA02009@chehalis.stanford.edu>
To: faculty@score
Subject: CSD potluck this Sunday
Don't forget the CSD potluck, our house, this Sunday, February 26, at 12
noon. Thus far we have lots of students and eight faculty
signed up, a promising start. Please come and help make this one of
the best faculty-attended departmental potlucks ever!
Here's the map again.
_________________________________________________| |__________________________
__________________________________Foothill______Light______Expressway_________
Vaughan and Margot Pratt |P|
Street address: 2215 Gerth Lane /.a|.....one way - no entry to
Los Altos Hills //|g| Old Page Mill Road
Phone: 494-2545 // |e|
<PO address: 2215 Old Page Mill Rd. // | |
Palo Alto, CA 94304> Old || |M|
DIRECTIONS Page|| |i|
Take Page Mill to near 280 Mill|| |l|
Follow sign to Old Page Mill Road Road|| |l|
Gerth Lane has row of mailboxes............|| Light_________________________
:|| |E --------------------------
Cross bridge........................... :|| |x| Deer Creek Road
2215 is second on left....... : :|| |p|
: : :|| |w|
Gerth Lane : : :|| |y| only entry to
=================:=========#===:= === .!.....Old Page Mill Road
2215 2209 M \\ | | and Gerth Lane
<not to scale> \\| |
\ |
_________________________________________________| |_________________________
_<--SF______________________Route 280____________ _____________________SJ-->
∂24-Feb-89 1426 X3J13-mailer Issue: EXTENTIONS-POSITION
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 24 Feb 89 14:26:07 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA13754; Fri, 24 Feb 89 14:24:16 PST
Message-Id: <8902242224.AA13754@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA13754; Fri, 24 Feb 89 14:24:16 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 24 Feb 89 17:23
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: EXTENTIONS-POSITION
Issue: EXTENSIONS-POSITION
References: Chapter 1, Working draft of standard
Category: Clarification
Related Issues: CONFORMANCE-POSITION, IF-BODY, ERROR-TERMINOLOGY, EXTRA-SYNTAX,
EXTRA-OPTIONAL-KEYWORD-ARGUMENTS, UNSPECIFIED-
Edit history: 12-DEC-88, Version 1 by Chapman
20-DEC-88, Version 2 by Chapman
9-JAN-89, Version 3 by Chapman
10-JAN-89, Version 4 by Chapman
2-FEB-89, Version 5 by Chapman
24-FEB-89, Version 6 by Chapman (added RPG's comment)
Problem Description:
What is the definition of a language extension?
What effect does a language extension have on a conforming program?
What obligation does an implementation have to warn the user that an
extension is being used?
Presumably the only thing that defining it as an extension can mean from
CL's point of view is `initially defining' it as an extension. Whether
an implementation permits redefinition of an extension is between that
implementation and its users and beyond the scope of Common Lisp. For
example, it is common practice to redefine some kinds of system functions
in Genera -- to extend the system in interesting ways, to fix bugs, etc.
Proposal (EXTENSIONS-POSITION:DOCUMENTATION)
The standard document should define a language extension to be
any implementation-supplied tool that isn't explicitly defined
in the standard. This includes facilities added to tools defined
in the standard.
The standard document should levy the following requirement on a
conforming implementation's documentation:
The documentation that accompanies a conforming implementation should clearly
state which parts of the implementation are extensions.
If the standard says that "the results are unspecified", and an
implementation specifies the results, this an extension in the
sense that if the correct behavior of a program depends on the results,
only implementations with the same extension will execute the program
correctly.
In places where the standard says that "an implementation may be extended",
this implies that a conforming, but probably non-portable, program can
be written using the implementation's extension.
Proposal (EXTENSIONS-POSITION:DISABLE)
Same as EXTENSIONS-POSITION:DOCUMENTATION except that
an implementation is required to have a way to disable its extensions, so
that a programmer can be told when he is using a feature that might
affect his program's portability.
Rationale:
The standard should contain information about language extensions
since most implementations have extended the language.
Current Practice:
CLtL allows any extension, provided that it doesn't alter the behavior
of a program that only uses what is specified in CLtL. In particular,
any situation that "is an error" (either explicitly or implicitly) is a
potential area for extension.
Adoption Cost:
Vendors will have to improve their documentation
to list all their extensions. Vendors will have to go through their
implementation and determine what is or isn't an extension.
Benefits:
This definition will provide a basis for proper understanding of
the error terminology used in the standard. The implementation
documentation requirement will aid the user in producing portable code.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
Masinter says:
It seems to be a constraint on "documentation" rather than "implementation"
if you turn the accidental behavior of (CAR T) into a "feature" of your
implementation. We might want to disallow such an extension as "conforming
to the standard". An implementation which had such an extension might
conform, even if the extension did not conform.
RPG says:
I favor remaining mute on this topic in the standard.
∂24-Feb-89 1429 @Score.Stanford.EDU:gio@sumex-aim.stanford.edu Re: A Proposal to Change Initial Student Support
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 89 14:29:29 PST
Received: from sumex-aim.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 24 Feb 89 14:27:15-PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA24724; Fri, 24 Feb 89 14:26:46 PST
Resent-Message-Id: <8902242226.AA24724@sumex-aim.stanford.edu>
Return-Path: <ejm@shasta.stanford.edu>
Received: from shasta.stanford.edu by sumex-aim.stanford.edu (4.0/inc-1.0) id
AA16131; Fri, 24 Feb 89 09:40:45 PST
Received: by shasta.stanford.edu; Fri, 24 Feb 89 09:37:18 PST
Date: Fri 24 Feb 89 09:37:15-PST
From: Ed McCluskey <EJM@shasta.arpa>
Subject: Re: A Proposal to Change Initial Student Support
To: gio@sumex-aim.stanford.edu
Message-Id: <VAX-MM(187)+TOPSLIB(118) 24-Feb-89 09:37:15.SHASTA.ARPA>
In-Reply-To: Message from "Gio Wiederhold <gio@sumex-aim.stanford.edu>" of
Wed, 22 Feb 1989 14:29:42 PST
Resent-To: faculty@score.stanford.edu
Resent-Date: Fri, 24 Feb 1989 14:26:44 PST
Resent-From: Gio Wiederhold <gio@sumex-aim.stanford.edu>
yuesλλλes λ, let's do it!
Ed McCluskey
-------
∂24-Feb-89 1437 X3J13-mailer Issue: EXTRA-RETURN-VALUES
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 24 Feb 89 14:37:35 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA14585; Fri, 24 Feb 89 14:35:46 PST
Message-Id: <8902242235.AA14585@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA14585; Fri, 24 Feb 89 14:35:46 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 24 Feb 89 17:35
To: x3j13@sail.stanford.edu
Subject: Issue: EXTRA-RETURN-VALUES
Issue: EXTRA-RETURN-VALUES
References: Chapter 1, Section 1.5, Working draft of standard
Category: Clarification
Edit history: 8-JAN-89, Version 1 by Masinter
3-FEB-89, Version 2 by Chapman
Problem: Is it OK to return extra values from Common Lisp functions?
Proposal: EXTRA-RETURN-VALUES:NO
Unless it is explicitly allowed in the standard,
if a standard function
returns a different number of return values from the number
specified by the standard, the results are unspecified.
Rationale:
The reason is that
additional arguments are visible to otherwise portable programs. "For
instance, (multiple-value-call #'cons (floor x y)) looks portable, but it
will try to pass the wrong number of arguments to CONS if FLOOR returns an
extra value."
Current Practice:
Adoption Cost:
Implementations and their associated documentation that now contain
functions that return extra values will have to change.
Benefits:
Programs will potentially become more portable.
Conversion Cost:
See Adoption Cost.
Aesthetics:
None.
Discussion:
∂24-Feb-89 1439 X3J13-mailer Issue: UNSPECIFIED-DATATYPES
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 24 Feb 89 14:38:57 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA14708; Fri, 24 Feb 89 14:37:07 PST
Message-Id: <8902242237.AA14708@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA14708; Fri, 24 Feb 89 14:37:07 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 24 Feb 89 17:36
To: x3j13@sail.stanford.edu
Subject: Issue: UNSPECIFIED-DATATYPES
Issue: UNPSECIFIED-DATATYPES
References: Chapter 1, Section 1.5, Working draft of standard
Category: Clarification
Edit history: 8-JAN-89, Version 1 by Masinter
6-FEB-89, Version 2 by Chapman
Problem: Is it OK to define the behavior of functions on datatypes not
explicitly permitted in the standard?
Proposal: UNPSECIFIED-DATATYPES:NO-EXCEPT-AS-EXPLICITLY-ALLOWED
A conforming implementation does not define the behavior of functions
on data types not explicitly permitted in the standard.
Example: A conforming implementation is not allowed to define + as
operating on vectors.
Rationale:
While the original intent of CL designers was that
implementations be permitted to do these things, they get in the way of
portability when they're done, since it is nearly impossible to detect when
a program has used one of these features. It is simple to define a new
function
acme-common-lisp:+ which has the behavior of the "portable" + plus all the
new whizzy features, too.
Current Practice:
Adoption Cost:
Implementors would have to determine which functions had been allowed
to operate on data types not explicitly allowed in CLtL and rewrite those
functions. The implementation's documentation would have to change.
Benefits:
Portability.
Conversion Cost:
See Adoption Cost.
Aesthetics:
None.
Discussion:
"The suggestion that implementations can shadow standard functions to
provide these features has been made before, and I'll repeat my standard
objection. The behavior of a standard function is also apparent when
calling a portable function that is defined to use that function. A
good example is FORMAT: a portable subroutine library would be quite
likely to define functions that take FORMAT-style argument lists
(Pitman's portable condition system defines several). If an
implementation extends FORMAT, these extensions should be reflected in
the behavior of these functions. But if the extensions are hidden in
ACME:FORMAT and the library calls LISP:FORMAT, this won't happen, and
there's no way to make it happen without modifying the library's source."
∂24-Feb-89 1439 X3J13-mailer Issue: MACRO-AS-FUNCTION
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 24 Feb 89 14:38:14 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA14651; Fri, 24 Feb 89 14:36:25 PST
Message-Id: <8902242236.AA14651@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA14651; Fri, 24 Feb 89 14:36:25 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 24 Feb 89 17:36
To: x3j13@sail.stanford.edu
Subject: Issue: MACRO-AS-FUNCTION
Issue: MACRO-AS-FUNCTION
References: Chapter 1, Section 1.5, Working draft of standard
Category: Clarification
Edit history: 8-JAN-89, Version 1 by Masinter
6-FEB-89, Version 2 by Chapman
Problem:
May operators defined in the standard as "macros" and
"special forms" be implemented as functions instead? PROG1 is the main
example, but there might be others.
Proposal: MACRO-AS-FUNCTION:YES
Operators that are defined in CL as "macros" may be defined as functions
instead if the semantics can be preserved.
This is rare, perhaps only
restricted to
(defun prog1 (value &rest ignore) value)
(defun prog2 (value1 value2 &rest ignore) value2)
Operators defined as "special forms" may also be defined as functions.
Alternate Proposal: MACRO-AS-FUNCTION:STATUS-QUO
The standard will remain silent on the issue of whether or not is
is legal for an implementation to implemention "macros" and
"special forms" as functions.
Alternate Proposal: MACRO-AS-FUNCTION:DISALLOW
A conforming implementation does not define "macros" and "special forms"
as functions.
Rationale:
There isn't a good reason to disallow "macro" and "special form" function
definitions. It doesn't interfere with portability.
Current Practice:
One implementation defines PROG1 as a function.
Adoption Cost:
None for :YES; some for :DISALLOW.
Benefits:
Increased implementation flexibility.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
∂24-Feb-89 1439 X3J13-mailer Issue: UNSOLICITED-MESSAGES
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 24 Feb 89 14:39:14 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA14750; Fri, 24 Feb 89 14:37:23 PST
Message-Id: <8902242237.AA14750@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA14750; Fri, 24 Feb 89 14:37:23 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 24 Feb 89 17:37
To: x3j13@sail.stanford.edu
Subject: Issue: UNSOLICITED-MESSAGES
Issue: UNSOLICITED-MESSAGES
References: Chapter 1, Section 1.5, Working draft of standard
Category: Clarification
Edit history: 8-JAN-89, Version 1 by Masinter
6-FEB-89, Version 2 by Chapman
Problem: Is it legal for an implementation to produce unsolicited output,
e.g., GC notifications, autoload heralds, and progress messages from
COMPILE-FILE or LOAD?
Proposal: UNSOLICITED-MESSAGES:NOT-TO-SYSTEM-USER-STREAMS
Unsolicited messages, such as GC notifications and autoload heralds, if
they are produced by an implementation, should not be directed to
*STANDARD-OUTPUT*, *ERROR-OUTPUT*. If an implementation produces them, they
may be produced on a stream that is not "shared" with any of the streams
that a user might redefine or redirect. (This really means that it is OK to
direct such notifications to *TERMINAL-IO* since a user may not redirect
*TERMINAL-IO*.)
Messages such as progress reports from LOAD and COMPILE are "solicited",
and are not covered by this issue. See issue COMPILE-AND-LOAD-VERBOSE.
Rationale:
This proposal has very little impact on implementations, but helps the
user by explicitly stating the disposition of unsolicited messages.
Current Practice:
Adoption Cost:
Small. Implementations and their documentation may have to change slightly.
Benefits:
Portability.
Conversion Cost:
See Adoption Cost.
Aesthetics:
None.
Discussion:
∂24-Feb-89 1524 TAJNAI@Score.Stanford.EDU Important dates for 1990
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 89 15:24:30 PST
Date: Fri 24 Feb 89 15:20:38-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Important dates for 1990
To: csd@Score.Stanford.EDU, faculty@Score.Stanford.EDU, sec@Score.Stanford.EDU
Message-ID: <12473328641.18.TAJNAI@Score.Stanford.EDU>
Monday, Feb. 12, 1990: 7:30 p.m. first Forsythe lecture
Tuesday, Feb. 13: 4:15 p.m. second Forsythe lecture
6:00 p.m. Computer Forum 22nd Annual Meeting
Informal Buffet Supper, Faculty Club
Wednesday, Feb. 14: 8:00 a.m. Computer Forum Registration and
buffet breakfast, Tresidder
sessions
6:00 p.m. Forum banquet
Thursday, Feb. 15: 8:00 a.m. Forum continues
sessions
4:30 p.m. to 6:00 Forum reception for all CSD/CSL
and friends will close the conference.
Although attendance was good last week, a number of faculty and
research associates had conflicting commitments. On behalf of the Department
of Computer Science and the Computer Systems Laboratory, we ask that
you reserve these dates now, and give the Forum conference priority.
We thank the faculty, students, staff and the Forum committee for making
the meeting last week a huge success. Feel free to send suggestions for
next year's 22nd Annual Meeting.
Carolyn Tajnai
-------
∂24-Feb-89 1609 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu ADVANCE PROGRAM FOR STOC '89
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 89 16:09:24 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA06637; Fri, 24 Feb 89 16:06:50 -0800
Message-Id: <8902250006.AA06637@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Fri, 24 Feb 89 16:07:11 PST
Received: by BYUADMIN (Mailer R2.01A) id 1173; Fri, 24 Feb 89 16:58:05 MST
Date: Fri, 24 Feb 89 13:16:37 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Richard Ladner <ladner@KINGFISHER.CS.WASHINGTON.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Richard Ladner <ladner@KINGFISHER.CS.WASHINGTON.EDU>
Subject: ADVANCE PROGRAM FOR STOC '89
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Symposium on Theory of Computing
Twenty-First Annual
May 15-17, 1989
Seattle, Washington
Local Arrangements Chair: Richard Ladner
Program Committee Chair: Christos Papadimitriou
Program Committee:
Fan Chung Nancy Lynch
Cynthia Dwork Christos Papadimitriou
Faith Fich Vijaya Ramachandran
Shafi Goldwasser Eva Tardos
Debby Joseph Avi Wigderson
Maria Klawe Frances Yao
------------------------------------------------------------------------------
STOC'89
Advance Registration Form
Please send this form or a facsimile, along with a check or money
order made out to ACM STOC '89, to:
Richard Ladner
Department of Computer Science, FR-35
University of Washington
Seattle, WA 98195
(Attn: STOC Registration)
Registration Fee By 4/25/89 After 4/25/89
ACM or SIGACT Member $190 $240
Neither ACM nor SIGACT Member $200 $250
Author or Program Committee Member $180 $230
Full-time Student $50 $100
Registration fee includes 3 lunches, 1 outing, coffee breaks, and the
proceedings. Student registration fee includes lunches, coffee breaks
and proceedings, but not the outing. Additional
outing tickets are $40 each. Circle the appropriate amount above.
Name__________________________________________________________________________
Affiliation___________________________________________________________________
Address_______________________________________________________________________
Address_______________________________________________________________________
City______________________________State______________________________Zip______
Country________________________________________________Phone__________________
E-mail________________________________________________________________________
Dietary restriction: Kosher Vegetarian
------------------------------------------------------------------------------
STOC '89
May 15-17, 1989
Hotel Reservation Form
Reservations should be made by April 23, 1989. To make reservations by
phone, 206-621-9000, Ext. 5555. When calling mention the dates of the
conference and the code STOC '89.
To make reservations by mail, return this form with check, money order,
or major credit card information, for the first night's deposit to:
Seattle Sheraton Hotel and Towers
1400 Sixth Avenue
Seattle, WA 98101
Single $95 Double $95 Triple $110 Quadruple $110
Name__________________________________________________________________________
Address_______________________________________________________________________
Address_______________________________________________________________________
City______________________________State______________________________Zip______
Day time phone________________________________________________________________
Arrival Date and Time_________________________________________________________
Departure Date and Time_______________________________________________________
Sharing room with_____________________________________________________________
Credit Card (if used)_________________________________________________________
Name on Credit Card___________________________________________________________
Credit Card No._______________________________________________________________
Expiration Date of Card_______________________________________________________
Signature_____________________________________________________________________
Reservations received after the contracted block of rooms is full or after
the cut-off date of April 23, 1989 are subject to space and rate availability.
Arrivals after 4:00 pm must guarantee first nights accommodations with
check, money order, or major credit card.
Fire codes require that triples or quadruples must use existing bedding.
------------------------------------------------------------------------------
Conference Information
Hotel Information. The Seattle Sheraton Hotel and Towers is a first-class
hotel located in downtown Seattle at 1400 Sixth Avenue, between Pike and
Union Streets. To make a reservation call 206-621-9000 Ext. 5555 or send
in the Hotel Reservation Form to the hotel. When calling mention the dates
of the conference and the code STOC '89. Room rates are $95 for a single
or double, $110 for a triple or quadruple. Fire codes require that triples
or quadruples must use existing bedding. The symposium rate will be honored
up to three days prior to and three days after the symposium. A block of
rooms is being held for the symposium until the cut-off date of
April 23, 1989. Reservations received after the block of rooms is full
or after the cut-off date of April 23, 1989 are subject to space and rate
availability. Check-in time is 3:00 pm and Check-out time is 1:00 pm.
Transportation. If you are flying you will arrive at Seattle-Tacoma
Internationl Airport (SEA-TAC) which is about 15 miles south of downtown
Seattle. The Airport Express (Gray Line) runs about every 30 minutes from
outside the baggage claim area to the Sheraton and costs $5.50 one-way or
$10 round-trip. A taxi to the Sheraton costs about $22. To reach the
hotel by car going north on I-5, exit on the left at the Seneca Street
(exit 165), turn immediately right onto 6th and continue three blocks to
the hotel on the right. Going south on I-5, exit on the right at Union
Street (exit 165B), the hotel is immediately on your right between 6th
and 7th. Going west on I-90, exit onto I-5 north (exit 2C),then exit I-5
at Madison. Turn left on Madison, then right onto
6th and continue 5 blocks to the hotel.
Airline Information. American Airlines has been designated the official
carrier of STOC '89 offering special fares to North American conferees.
>From within the contiguous 48 States, American will allow 5% off any
promotional air fare for which you qualify, 45% off regular day coach
air fare with a 14 day advance purchase, or 40% off regular day coach
air fare with a 7 day advance purchase. From within Canada, American
will allow 35% off regular day coach fare with a 7 day advance
purchase. These fares are valid for travel dates between 5/7/89 and
5/24/89. To take advantage of these fares you or your travel agent should
call 1-800-433-1790 and ask for Star File #S-0759WE.
Outing. On Tuesday evening our group will take a short bus ride to the
waterfront where we will board a boat to cross Puget Sound to Kiana Lodge.
At Kiana we can enjoy their lovely gardens and be treated to a Northwest
salmon feast. Busses depart the hotel at 5:20 and return about 9:30.
The boat trip is about 50 minutes each way and may be chilly. The outing is
included in the registration fee, except for those paying the student
registration fee. Additional outing tickets may be purchased for $40.
Registration. There will be registration outside of the Cirrus Room
on Sunday, May 14, from 8:00 to 10:00 pm. From Monday to Wednesday there
will be a registration and information desk set up outside the Grand
Ballroom from 8:30 am to 5:00 pm .
Information about Seattle. Seattle is a beautiful city of 500,000 people
located on the shores of Lake Washington and Puget Sound. The Cascade
Mountains to the east and Olympic Mountains to the west can both be viewed
from the city. Mount Rainier (14,411 ft. or 4,434 m. tall) looms
in the distance some 90 miles away. In mid May the temperature range
is typically between 50F (10C) and 70F (21C). Cloudy days with occasional
rain can be expected with probability about 1/2.
Things To Do. There is much to do in the city during breaks at the
conference. Washington State has many attractions if you plan to come
before or stay after the conference. To obtain a statewide travel planning
guidecall 1-800-544-1800. A restaurant guide will be given out at the
conference.
Downtown, within walking distance or within the free bus zone. Yes,
the city busses are free in the downtown area before 9 pm.
- Pike Place Market (6 blocks west on Pike Street). This is an open
air public market with many indoor and outdoor shops.
- Waterfront (a short walk down stairs from Pike Place Market).
On the waterfront you can visit the Seattle Aquarium, Omnidome
with fantastic Mt. Saint Helens movie footage, Washington State
ferries, and harbor boat tours.
- Pioneer Square (10 blocks south of Pike Place Market on free bus
lines). This is an historic area of Seattle with the Underground
Tour, many galleries and shops, Elliot Bay Bookstore and Cafe,
Smith Tower, and Kingdome Stadium.
- International District (14 blocks south of the hotel and just east
of the Kingdome). This is a small area populated with many
oriental restaurants.
- Convention Center and Freeway Park (just east of the hotel).
- Downtown Shopping (just west of the hotel). Many nice stores
includin Eddie Bauer, Nordstroms, I. Magnin, and the small shops
in the new Westlake Center are nearby.
Within Seattle and can be easily reached by city bus. Busses fares are
55 cents during non-peak hours and 75 cent during peak hours. On busses
going out of Downtown you pay on getting off the bus and on busses going
toward Downtown you pay on getting on the bus. You must have exact change.
- Capitol Hill. An off beat area about just east of Downtown.
The main attraction is Broadway which has many shops and eating
places. Special attractions there are the art cinemas
the Harvard Exit and the Egyptian. Volunteer park has a very
nice art museum and plant conservatory. A retail store of the mail
order house REI is on Capitol Hill.
- University District. This area surrounds the beautiful University of
Washington campus. Nearby is the University Arboretum with a
splendid Japanese Garden.
- Seattle Center. This is an enclosed campus which houses the
Space Needle, an amusement park, Pacific Science Center, Bagley
Wright Theatre, Opera House, Intiman Theatre, and ACT Theatre.
Seattle Center is reachable from Downtown by an elevated
monorail.
- Ballard Locks, Shilshole Marina, Golden Gardens Park, and Discovery
Park. (four attractions very near each other in the northwest part
of the city). The Ballard Locks connect the salt water Puget Sound
to fresh water Lake Washington. This is a great place to go
boat watching on weekends. Shilshole Marina is a moorage for about
1,500 sail boats. Golden Gardens is a beach on Puget Sound and
Discovery Park is a huge undeveloped park where a pair of Bald
Eagles have a nest.
- Woodland Park Zoo and Green Lake (adjacent attractions). The Zoo has
great African savannah and Gorilla exhibits. Green Lake is a
jogger's paradise, a 2.6 mile (4.3 k) run around a park surrounded
lake. Those two Bald Eagles which are nesting in Discovery
Park seem to spend their afternoons at Green Lake.
Outside Seattle requiring an automobile to get there.
- Museum of Flight near Boeing Field (15 minutes South).
- Boeing Tour of 747 Plant in Everett (30 minutes North).
- Ste.Michelle Winery (30 minutes Northeast).
- Mt. Rainier (3 hours south). There is Paradise Lodge and a
visitors' center near the 6000 foot (1850 meter) level on the
south face of Rainier. The trails will be snow-covered
at this time. You should be able to see Rainier from I-5
as you leave from the south end of Seattle otherwise you may
not see anything at 6000 feet either.
- Mt. Saint Helens (3.5 hrs south). The last parts of this route
are on well maintained one lane forest service roads with turnouts.
On a clear day there are also good views of Mt. Rainier, Mt. Adams,
and Mt. Hood as well as Mt. St. Helens. Check that this road is
open since that may depend on the snow pack. Hiking trails are
probably snow-covered.
- North Cascades (1.5-2 hrs northeast). The North Cascades loop
highway travels through some beautiful jagged mountains.
Most of the trails will be snow/ice covered. The full
loop is a very long drive but interesting places crop up
fairly quickly.
- Steven's Pass-Cascades (1-1.5 hr northeast). Highway 2 through the
mountains travels through a somewhat less rugged area than the
North Cascades. Most areas below the pass should have good
snow-free hiking areas.
- Snoqualmie Pass-Cascades (1 hr east). Lowest of the passes through
the Cascades, following I-90. Several hikes along the way,
also along the way is Snoqualmie Falls, a pleasant park setting with
waterfall very popular with Sunday picnickers in the summer.
- Olympic Peninsula (2-3 hrs west). Reachable either by ferry and
across Hood Canal Bridge to the north or through Olympia to the
south. Several very different areas to explore. The Hurricane Ridge
visitor center in the Olympic mountains is reachable an hour
south from Port Angeles. The Pacific coast (another 2 hrs) has
some of the most rugged shorelines in the continental U.S.
The west side of the Olympics also creates middle latitude rain
forests in several places. Many trails on the east side of the
Olympics should be hikable in May.
- San Juan Islands (2.5 hours north by car then ferry).
Beautiful cluster of islands with small resorts and towns.
Many bed-and-breakfasts can be found for overnight stays.
- Victoria B.C.(2.5-4.5 hrs by boat). There is no need to take a car
to enjoy Victoria. From Seattle take either the Princess Marguerite
(slow boat) or Victoria Clipper (fast boat).
- Vancouver B.C. (3 hrs North).
Further Information. For further information contact Richard Ladner,
Department of Computer Science, University of Washington,
Seattle, WA 98195, 206-543-9347, E-mail: ladner@cs.washington.edu.
------------------------------------------------------------------------------
STOC '89 Program
All events except the outing are held at the Seattle Sheraton. All technical
sessions and lunches will be held in the Grand Ballroom on the second
floor. Other events will be in rooms indicated in the program.
During the day there will be rooms on the second floor available for
small meetings.
Sunday Evening, May 14, 1989
RECEPTION: 8:00 - 11:00, in the Cirrus Room on the 35th floor.
Video Tape of AAAS Academic Funding Panel can be viewed nearby.
Monday, May 15,1989
SESSION 1: 8:30 - 10:10, chaired by Shafi Goldwasser, M.I.T.
8:30 "Multiparty protocols and logspace-hard pseudorandom sequences,
"Laszlo Babai, Univ. of Chicago and Eotvos University, Hungary,
Noam Nisan, UC Berkeley, and Mario Szegedy, Univ.of Chicago.
8:50 "Pseudo-random Number Generation from ANY One-way Function,"
Russell Impagliazzo, UC Berkeley, Leonid Levin, Boston University,
and Michael Luby, Univ. of Toronto.
9:10 "A Hard-Core Predicate for All One-Way Functions," Oded Goldreich,
Technion, Israel, and Leonid A. Levin, Boston University.
9:30 "Universal One-Way Hash Functions and their Cryptographic
Applications," Moni Naor, UC Berkeley, and Moti Yung, IBM Yorktown.
9:50 "Limits on the Provable Consequences of One-way Permutations,"
Russell Impagliazzo, UC Berkeley, and Steven Rudich, Univ. of Toronto.
BREAK: 10:10 - 10:40
SESSION 2: 10:40 - 12:00, chaired by Cynthia Dwork, IBM Almaden Research
Center
10:40 "A Zero-One Law for Boolean Privacy," Benny Chor and Eyal Kushilevitz,
Technion, Israel.
11:00 "Verifiable Secret Sharing and Multiparty Protocols with Honest
Majority," Tal Rabin and Michael Ben-Or, The Hebrew University, Israel.
11:20 "Designing Programs that Check Their Work," Manuel Blum and
Sampath Kannan, UC Berkeley.
11:40 "Provably Fast Integer Factoring with Quasi-uniform Small
Quadratic Residues," Brigette Vallee, Univ. de Caen, France.
LUNCH: 12:00 - 1:20
SESSION 3: 1:20 - 3:20, chaired by Debby Joseph, Univ. of Wisconsin at Madison
1:20 "Functional Interpretations of Feasibly Constructive Arithmetic,"
Stephen Cook and Alasdair Urquhart, Univ.of Toronto.
1:40 "Expressiveness of Restricted Recursive Queries," Foto Afrati,
National Technical University of Athens, Greece, and Stavros S. Cosmadakis,
IBM T. J. Watson Research Center.
2:00 "On w-Automata and Temporal Logic," Shmuel Safra, Weizmann Institute,
Israel, and Moshe Y. Vardi, IBM Almaden Research Center.
2:20 "Quantifier Elimination in the Theory of Algebraically-Closed Fields,"
Doug Ierardi, Cornell University.
2:40 "Probabilistic Computation and Linear Time," Lance Fortnow and
Michael Sipser, M.I.T.
3:00 "The Isomorphism Conjecture Fails Relative to a Random Oracle,"
Stuart A. Kurtz, Univ. of Chicago, Stephen R. Mahaney, AT&T Bell
Laboratories, and James S. Royer, Univ. of Chicago.
BREAK: 3:20 - 3:40
SESSION 4: 3:40 - 5:40, chaired by Avi Wigderson, Hebrew University, Israel
3:40 "On the Method of Approximations," A. A. Razborov, Steklov Mathematical
Institute, USSR.
4:00 "On the Extended Direct Sum Conjecture," Nader H. Bshouty, Technion,
Israel.
4:20 "Circuits and Local Computation" Andrew Chi-Chih Yao, Princeton
University.
4:40 "A General Sequential Time-Space Tradeoff for Finding Unique Elements,"
Paul Beame, Univ.of Washington.
5:00 "Towards a Theory of Average Case Complexity," Shai Ben-David,
Benny Chor, and Oded Goldreich, Technion, Israel, and Michael Luby,
Univ.of Toronto.
5:20 "Tradeoffs Between Communication and Space," Tak Lam, Univ. of
Washington, Prasoon Tiwari and Martin Tompa, IBM T. J. Watson Research Center
SIGACT BUSINESS MEETING: 8:30 - 11:00 in Metropolitan Ballroom on
third floor
Tuesday, May 16, 1989
SESSION 5: 8:30 - 10:10, chaired by Maria Klawe, University of British
Columbia
8:30 "Work-Preserving Simulations of Fixed-Connection Networks,"Richard Koch,
Bruce Maggs, and Satish Rao, M.I.T., and Arnold Rosenberg Univ. of
Massachusetts, Amherst.
8:50 "An O(log N ) Deterministic Packet Routing Scheme," Eli Upfal, IBM
Almaden Research Center.
9:10 "Fast Computation Using Faulty Hypercubes," JohanHastad, Royal
Institute of Technology, Sweden, and Tom Leighton and Mark Newman, M.I.T.
9:30 "Optimal Size Integer Division Circuits," John H. Reif and
Stephen R. Tate, Duke University.
9:50 "On the Complexity of Radio Communication," Noga Alon,
Tel Aviv University, Israel, Amotz Bar-Noy, Stanford University, Nathan
Linial, IBM Almaden Research Center, and David Peleg,
Weizmann Institute, Israel, and Stanford University.
BREAK: 10:10 - 10:40
SESSION 6: 10:40 - 12:20, chaired by Vijaya Ramachandran, Univ. of Texas
at Austin
10:40 "Local Reorientation, Global Order, and Planar Topology,"
Ming-Yang Kao and Gregory E. Shannon, Indiana University, Bloomimgton.
11:00 "Parallel Depth-First Search in General Directed Graphs," Alok Aggarwal,
T.J. Watson Center, Richard J. Anderson, University of Washington,
and Ming-Yang Kao, Indiana University, Bloomington.
11:20 "Highly Parallelizable Problems," Omer Berkman and Dany Breslauer,
Tel Aviv University, Israel, Zvi Galil, Tel Aviv University, Israel,
and Columbia University, Baruch Schieber, IBM T. J. Watson Research Center,
and Uzi Vishkin, Tel Aviv University, Israel, and Univ. of Maryland.
11:40 "Optimal Separations Between Concurrent-write Parallel Machines,"
Ravi B. Boppana, Rutgers University.
12:00 "CREW PRAMS and Decision Trees," Noam Nisan, UC Berkeley.
LUNCH: 12:20 - 2:00
SESSION 7: 2:00 - 3:20, chaired by Faith Fich, Univ. of Toronto
2:00 "Implicit O(1) Probe Search," Amos Fiat and Moni Naor, UC Berkeley.
2:20 "The Cell Probe Complexity of Dynamic Data Structures," Michael Fredman,
Bellcore and UCSD, and Michael Saks, UCSD, Bellcore, and Rutgers University.
2:40 "On Aspects of Universality and Performance for Closed Hashing,"
Jeanette P. Schmidt, Rutgers University, and Alan Siegel, NYU.
3:00 "Verifying Partial Orders," Claire Kenyon-Mathieu and Valerie King,
Princeton University.
BREAK: 3:20 - 3:40
SESSION 8: 3:40 - 5:00, chaired by Frances Yao, Xerox Palo Alto
Research Center
3:40 "A Random Polynomial Time Algorithm for Approximating the Volume of
Convex Bodies," Martin Dyer, Univ. of Leeds, United Kingdom, and Alan Frieze
and Ravi Kannan, CMU.
4:00 "Lines in Space-Combinatorics, Algorithms and Applications" Bernard
Chazelle, Princeton University, Herbert Edelsbrunner, Univ. of Illinois at
Urbana-Champaign, Leonidas Guibas, DEC Systems Research Center and Stanford
University, and Micha Sharir, NYU and Tel Aviv University, Israel.
4:20 "Polling: A New Randomized Sampling Technique for
Computational Geometry," John H. Reif and Sandeep Sen, Duke University.
4:40 "Coordinate Representation of Order Types Requires Exponential Storage,"
Jacob E. Goodman, City College, CUNY, Richard Pollack, NYU, and Bernd
Sturmfels, Johannes-Kepler Univ., Austria.
OUTING TO KIANA LODGE: 5:20 - 9:30
INFORMAL MEETING ON ACADEMIC FUNDING: 9:30 - 11:00, in Meeting Room
426 on fourth floor, chaired by Barbara Simons, IBM Almaden Research Center
Wednesday, May 17, 1989
SESSION 9: 8:30 -9:50, chaired by Christos Papadimitriou, UCSD
8:30 "Inference of Finite Automata Using Homing Sequences," Ronald L. Rivest
and Robert E. Schapire, M.I.T.
8:50 "The Minimum Consistent DFA Problem Cannot Be Approximated within any
Polynomial," Leonard Pitt, Univ.of Illinois at Urbana, Champaign, and
Manfred K. Warmuth, UC Santa Cruz.
9:10 "Cryptographic Limitations on Learning Boolean Formulae and Finite
Automata, "Michael Kearns and Leslie G. Valiant, Harvard University.
9:30 "Proof of a Conjecture of R. Kannan," Jean-Camille Birget, Univ. of
Nebraska.
BREAK: 9:50 - 10:20
SESSION 10: 10:20 - 12:00, chaired by Nancy Lynch, M.I.T.
10:20 "Bounded Concurrent Time-Stamp Systems Are Constructible!" Danny Dolev,
IBM Almaden Research Center and Hebrew University, Israel, and Nir Shavit
Hebrew University, Israel.
10:40 "On the Improbability of Reaching Byzantine Agreements," Ronald
L. Graham, AT&T Bell Laboratories, and Andrew C. Yao Princeton University.
11:00 "Compact Distributed Data Structures for Adaptive Routing,"
Baruch Awerbuch, M.I.T., Amotz Bar-Noy, Stanford University, Nathan Linial,
IBM Almaden Research Center and Hebrew University, Israel, and David Peleg,
Weizmann Institute, Israel.
11:20 "Reliable Communication Using Unreliable Channels," Hagit Attiya,
Michael J. Fischer, Da-Wei Wang, and Lenore D. Zuck, Yale University.
11:40 "Randomized Distributed Shortest Paths Algorithms,"
Baruch Awerbuch, M.I.T.
LUNCH: 12:00 - 1:30
SESSION 11: 1:30 - 2:50, chaired by Fan Chung, Bellcore
1:30 "On Search, Decision and the Efficiency of Polynomial-Time Algorithms,"
Michael R. Fellows, Univ.of Idaho, and Michael A. Langston, Washington State
University.
1:50 "A New Fixed Point Approach for Stable Networks and Stable Marriages,"
Tomas Feder, Stanford University.
2:10 "Strongly Polynomial-Time and NC Algorithms for Detecting Cycles in
Dynamic Graphs" Edith Cohen, Stanford University, and Nimrod Megiddo, IBM
Almaden Research Center and TelAviv University, Israel.
2:30 "An O(n~0.4)-Approximation Algorithm for 3-Coloring," Avrim Blum, M.I.T.
BREAK: 2:50 - 3:20
SESSION 12: 3:20 - 5:00, chaired by Eva Tardos, M.I.T. and Eotvos Univ.,
Hungary
3:20 "Trading Space for Time in Undirected s-t Connectivity,"
Andrei Z. Broder and Anna R. Karlin, DEC Systems Research Center,
Prabhakar Raghavan, IBM T. J. Watson Research Center, and Eli Upfal,
IBM Almaden Research Center.
3:40 "Expanding Graphs and the Average-case Analysis of Algorithms for
Matchings and Related Problems," Rajeev Motwani, Stanford University.
4:00 "New Lower Bounds on the Length of Universal Traversal Sequences,"
Allan Borodin, Univ. of Toronto, Walter L. Ruzzo, Univ. of Washington,
and Martin Tompa, IBM T. J. Watson Research Center.
4:20 "The Electrical Resistance of a Graph Captures its Commute and Cover
Times," Ashok K. Chandra and Prabhakar Raghavan, IBM T. J. Watson
Research Center, Walter L. Ruzzo, Univ. of Washington, Roman Smolensky,
UC Berkeley, and Prasoon Tiwari, IBM T. J. Watson Research Center.
4:40 "On the Second Eigenvalue of Random Regular Graphs." Joel Friedman,
Princeton University, Jeff Kahn, Rutgers University, and Endre Szemeredi,
Rutgers University and Hungarian Academy of Sciences.
END OF THE CONFERENCE: 5:00
------------------------------------------------------------------------------
∂25-Feb-89 0941 LOGMTC-mailer Logic Seminar
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Feb 89 09:41:52 PST
Received: by csli.Stanford.EDU (4.0/inc-1.0)
id AA29797; Sat, 25 Feb 89 09:39:52 PST
Date: Sat 25 Feb 89 09:39:51-PST
From: Sol Feferman <SF@CSLI.Stanford.EDU>
Subject: Logic Seminar
To: Logic@csli.Stanford.EDU
Message-Id: <604431591.0.SF@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
Speaker: Prof. Jouko Vaananen, Univ. of Helsinki, vis. UCLA
Title: "Trees, games and induction"
Time: Tues., Feb. 28. 4:15-5:30 PM
Place: Room 381-T, Math Corner, Stanford
Abstract:
The aim of this talk is to develop a theory of induction along
non-well-founded orderings. Our notion of inductive definability
is based on a transfinite game the length of which is measured
by the length of branches in a given tree. We describe a well-founded
ordering of trees which enables us to define a notion of rank
for this induction. We use this concept for studying various
aspects of uncountability such as definability theory of
uncountable models, model theory of infinite quantifier
languages and properties of uncountable trees.
***
There will be a dinner with the speaker after the talk.
S. Feferman
-------
∂26-Feb-89 1350 @Score.Stanford.EDU:Mailer@SAIL.Stanford.EDU
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Feb 89 13:47:14 PST
Received: from SAIL.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sun 26 Feb 89 13:44:19-PST
Message-ID: <96r4L@SAIL.Stanford.EDU>
Date: 26 Feb 89 1343 PST
From: John McCarthy <JMC@SAIL.Stanford.EDU>
To: "@CORREC.LIS[W89,JMC]"@SAIL.Stanford.EDU
The following statement was passed unanimously at a meeting
of the Computer Science Department faculty on Tuesday, Feb 21,
1989.
Statement of Protest about the AIR Censorship of rec.humor.funny.
Computer scientists and computer users have been involved in
making information resources widely available since the 1960s.
Such resources are analogous to libraries. The newsgroups
available on various networks are the computer analog of
magazines and partial prototypes of future universal computer
libraries. These libraries will make available the information
resources of the whole world to anyone's terminal or personal
computer.
Therefore, the criteria for including newsgroups in computer
systems or removing them should be identical to those for
including books in or removing books from libraries. For this
reason, and since the resource requirements for keeping
newsgroups available are very small, we consider it contrary to
the function of a university to censor the presence of newsgroups in
University computers. We regard it as analogous to removing a
book from the library. To be able to read anything subject only
to cost limitations is an essential part of academic freedom.
Censorship is not an appropriate tool for preventing or dealing
with offensive behavior.
We therefore think that AIR and SDC should rescind the purge of
rec.humor.funny. The Computer Science Department has also decided
not to censor Department Computers.
∂26-Feb-89 1446 hoffman@csli.Stanford.EDU The Symbolic Systems Forum, March 3rd
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Feb 89 14:46:31 PST
Received: by csli.Stanford.EDU (4.0/inc-1.0)
id AA23167; Sun, 26 Feb 89 14:32:31 PST
Date: Sun 26 Feb 89 14:32:30-PST
From: Reid Hoffman <HOFFMAN@CSLI.Stanford.EDU>
Subject: The Symbolic Systems Forum, March 3rd
To: ForumAnnouncement@csli.Stanford.EDU
Message-Id: <604535550.0.HOFFMAN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
The Symbolic Systems Forum presents.
Dr. Jeff Shrager
Intelligent Systems Lab
Xerox PARC
on
A Computational Psychology Approach to Commonsense Perception
Commonsense Perception is a generalized version of what Dretske has
called "epistemic seeing" -- that is, knowledge-based interpretation of
(perceptual) experience. In this talk I will outline a psychological
approach to the study of commonsense perception in incremental concept
learning. My goal is a computational framework and model whose basic
processing cycle is knowledge revision by commonsense perception, and
which subsumes rule-based inference, perceptual reasoning, and most
inductive and instructed learning tasks.
Date: Friday, March 3rd
Time: 3:15
Location: building 60, room 62n
The talk is open to the general public and refreshments will be served.
-------
∂26-Feb-89 2018 @Score.Stanford.EDU,@polya.Stanford.EDU:coraki!pratt@Sun.COM potluck report
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Feb 89 20:18:19 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Sun 26 Feb 89 20:15:40-PST
Received: from SUN.COM by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA14309; Sun, 26 Feb 89 20:11:28 -0800
Received: from sun.Sun.COM (sun-bb.sun.com) by Sun.COM (4.1/SMI-4.0)
id AA23178; Sun, 26 Feb 89 20:13:40 PST
Received: from coraki.UUCP by sun.Sun.COM (4.0/SMI-4.0)
id AA12601; Sun, 26 Feb 89 20:10:53 PST
Received: by (4.0/SMI-4.0Beta)
id AA13569; Sun, 26 Feb 89 20:10:10 PST
Date: Sun, 26 Feb 89 20:10:10 PST
From: Vaughan Pratt <coraki!pratt@Sun.COM>
Message-Id: <8902270410.AA13569@>
To: faculty@cs.stanford.edu
Subject: potluck report
Cc: coraki!pratt@Sun.COM
Eight of the seventy people listed under CSD Faculty and Research Staff
in the phone directory (p.147) came to the potluck. The potluck
organizers tell me this was a four-fold gain over the previous potluck,
but another four-fold gain would still be less than 50%. Suggestions
for making the event more attractive to faculty and staff are hereby
solicited. Should it be
* held less often?
* on a more favorable date and/or time?
* advertised more vigorously/attractively?
* catered instead of potluck?
* entertaining, featuring
a guest of honour? (I bet lunch Tuesday will be crowded.)
a general-interest talk?
games (parlor, lawn)?
* other?
-v
∂27-Feb-89 0207 @Score.Stanford.EDU:lam@k2.Stanford.EDU Re: A Proposal to Change Initial Student Support
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Feb 89 02:07:44 PST
Received: from k2.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 27 Feb 89 02:04:55-PST
Received: by k2.Stanford.EDU (5.59/inc-1.0)
id AA15404; Sun, 26 Feb 89 19:19:19 PDT
Date: 26 Feb 1989 19:01-PST
From: lam@k2.Stanford.EDU
Subject: Re: A Proposal to Change Initial Student Support
To: faculty@SCORE.STANFORD.EDU
Message-Id: <89/02/26 1901.880@k2.Stanford.EDU>
I think we should separate the funding issues with getting an advisor.
A student should have an advisor regardless of whether he needs
financial support or not.
We should simply make getting an advisor, say by the end of the first
quarter, part of the Ph.D. program. But if we do that, we must also
help the students in choosing an advisor by creating more opportunities
for the students to find out about the faculty and their research
projects.
-Monica
∂27-Feb-89 0217 X3J13-mailer Issue: EXTRA-SYNTAX
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 27 Feb 89 02:17:05 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA14142; Mon, 27 Feb 89 02:15:12 PST
Message-Id: <8902271015.AA14142@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA14142; Mon, 27 Feb 89 02:15:12 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 27 Feb 89 05:15
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: EXTRA-SYNTAX
Issue: EXTRA-SYNTAX
References: Chapter 1, Section 1.5, Working draft of standard
Category: Clarification
Related Issues: ERROR-TERMINOLOGY, EXTENSIONS-POSITION
Edit history: 8-JAN-89, Version 1 by Masinter
13-JAN-89, Version 2 by Chapman
3-FEB-89, Version 3 by Chapman
27-FEB-89, Version 4 by Chapman
Problem: is it OK to extend Common Lisp macros and special forms to take
additional syntax not specified?
Proposal: EXTRA-SYNTAX:NO
It isn't allowed.
Rationale:
It would be very difficult for a program-analyzing-program to detect
such an extension. Non-portable programs could easily result.
Current Practice:
Adoption Cost:
Benefits:
Conversion Cost:
Aesthetics:
None.
Discussion:
∂27-Feb-89 0218 X3J13-mailer Issue: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 27 Feb 89 02:18:42 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA14193; Mon, 27 Feb 89 02:16:50 PST
Message-Id: <8902271016.AA14193@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA14193; Mon, 27 Feb 89 02:16:50 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 27 Feb 89 05:16
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS
Issue: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS
References: Chapter 1, Section 1.5, Working draft of standard
Category: Clarification
Edit history: 8-JAN-89, Version 1 by Masinter
3-FEB-89, Version 2 by Chapman
27-FEB-89, Version 3 by Chapman
Problem:
Is it OK to define Common Lisp functions with extra optional or named arguments
with system-dependent meanings?
Proposal: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS:NO-EXCEPT-AS-ALLOWED
Unless explicitly allowed in the standard,
implementations are not allowed to include such definitions.
When extra optional or named arguments are allowed in the
standard, they will be annotated as follows:
functions that may be
extended to take implementation-specific optional arguments are indicated
by an &REST IGNORE in their argument list; functions that may be extended
to take additional keyword parameters are indicated by &ALLOW-OTHER-KEYS.
Rationale:
The goal is not to outlaw any extensions currently offered by
implementors, but to make the range of extensions to functions defined in
the standard well documented in the standard. Implementations that want to
extend functions that aren't explicitly allowed to be extended can instead
shadow them.
Alternate proposal: NOT-IN-STANDARD-PACKAGE
Like NO-EXCEPT-AS-ALLOWED, except that an implementation may always
provide additional named arguments to a function if the names are not in
an implementation-specific package (the list of these currently includes
the LISP, USER, and KEYWORD packages).
Current Practice:
Most implementations extend function syntax with extra
optional and named arguments.
Adoption Cost:
Implementors will be required to determine which parts of their implementations
are conforming and which parts aren't.
Implementors will have to provide a candidate list of exceptions to the
editorial committee.
Benefits:
It will be more possible to write portable programs. Also, future standards
will be less likely to make changes that are incompatible with current
implementations.
Conversion Cost:
See Adoption Cost.
Aesthetics:
None.
Discussion:
∂27-Feb-89 0255 X3J13-mailer Review schedule reminder
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 27 Feb 89 02:54:55 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA15941; Mon, 27 Feb 89 02:52:59 PST
Message-Id: <8902271052.AA15941@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA15941; Mon, 27 Feb 89 02:52:59 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 27 Feb 89 05:31
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Review schedule reminder
I would like to come to closure on several issues and sections of the
standard at the March meeting (i.e. take a vote on them). The complete
list is in issue CUT-OFF-DATES that I hope you have received either by
hardcopy mail or electronically. Below is a summary of what will be voted
on in March, and the dates I'm hoping to get comments from you. Please
see CUT-OFF-DATES for more details, or let me know if you didn't get that
issue.
Topic Suggested date for returning comments
______________________________________________________________________________
Conformance issues 3/1
CONFORMANCE-POSITION
EXTENSIONS-POSITION
SUBSETTING-POSITION
EXTRA-SYNTAX
EXTRA-OPTIONAL-KEYWORD-ARGUMENTS
MACRO-AS-FUNCTION
UNSOLICITED-MESSAGES
UNSPECIFIED-DATATYPES
Sections 1.1-1.5 3/1
Section 1.7 3/1
Sections 5.2-5.4 3/8
Section 1.6 3/15
Section 2.1 3/15
Section 5.1 (*) 3/15
Section 2.2 (**) 3/22
(*) This section is not complete as of now. Please do not review until
I let you know if will be worth your time.
(**) This section has undergone recent organizational changes. Please
do not review until after 3/1.
Please note that the dates above are only suggestions. Please feel free
to comment up to 3/21.
The sections of the standard are all available from hudson.dec.com
(ftp_user merrychristmas). Please see the file "how-to-build-standard.lis"
for information about file names.
I will also be sending you the sources from these sections electronically,
and will create a file named "march-27-ballot.tex" (and .dvi) that will contain
all these sections (except 5.1) and will be available after 3/1.
Please let me know if you have any trouble accessing or reviewing this
information. Note that after these sections have been voted in, we can
still change them with clean-up proposals.
kathy chapman
∂27-Feb-89 0851 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu faculty meetings
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Feb 89 08:51:37 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 27 Feb 89 08:50:53-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA12490; Mon, 27 Feb 89 08:47:31 PDT
Date: Mon, 27 Feb 89 08:47:31 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8902271647.AA12490@Tenaya.stanford.edu>
To: tenured@score
Cc: bureaucrat@polya
Subject: faculty meetings
Gene Golub inquires why don't we combine the full professor
faculty meeting to be held on Wed. Mar 1 with the assoc/full prof
faculty meeting to be held on Tue, Mar 7? Good question. I assumed
that we wouldn't be able to cover all the business at the Mar 1
meeting. This note is to inquire about:
1) Can the assoc profs come to the meeting on Wed. Mar 1 (this
is somewhat late notice)? If so, pls respond to Joyce saying
you will be there if held. The assoc and full profs will then
consider the Mike Clancy case. Letters on him are available from
Joyce and should be read before the meeting.
2) Are the full profs willing to stay a little longer at the Mar
1 meeting to consider the case they were going to consider that day
(but do so after the Clancy matter and after the assoc profs are
excused). Again, pls respond to Joyce if you are willing to do this.
Joyce will make a judgement call on the likely attendance and then
send a note out saying either that their will be one combined
meeting on Wed. Mar 1 at 4:15 or two meetings as previously planned.
In response to Gene's comment about having regular faculty meetings:
the only way I could deal with this would be to schedule a regular
faculty meeting every two weeks and then cancel most of them. Perhaps
those in favor of regular faculty meetings should consider them so
scheduled and then consider them all cancelled unless they hear
otherwise.
Yours for greater efficiency,
-Nils
∂27-Feb-89 0917 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu STOC Errata and Manuscripts
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Feb 89 09:17:41 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA28174; Mon, 27 Feb 89 09:15:27 -0800
Message-Id: <8902271715.AA28174@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Mon, 27 Feb 89 09:15:46 PST
Received: by BYUADMIN (Mailer R2.01A) id 8023; Mon, 27 Feb 89 10:14:27 MST
Date: Mon, 27 Feb 89 11:11:27 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Christos Papadimitriou <christos%cs@UCSD.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Christos Papadimitriou <christos%cs@UCSD.EDU>
Subject: STOC Errata and Manuscripts
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
If you have an erratum on an earlier STOC or FOCS paper for inclusion
in the Proceedings of the next STOC, please send a copy to me ASAP:
Christos Papadimitriou, CSE-C014, UCSD, La Jolla, CA 92093, U.S.A.
For the rest of this message, I apologize that I am using this route
in my effort to reach as many STOC authors as possible. All others,
please try to ignore what follows.
There are several problems associated with the letter, apparently
signed by me, that you received from ACM with the special forms. For starters,
I did not write it, or approve of it before it was sent. It neglects
to mention the page limit, which is TEN PAGES. And it contains an
error in its description of the dimensions of the forms (trust your
ruler rather than the letter).
I am expecting your paper any day now.
Regards to all,
---Christos Papadimitriou
∂27-Feb-89 0922 @Score.Stanford.EDU:golub@na-net.stanford.edu Re: faculty meetings
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Feb 89 09:22:48 PST
Received: from bravery.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 27 Feb 89 09:21:59-PST
Received: by bravery.stanford.edu (4.0/inc-1.5)
id AA10466; Mon, 27 Feb 89 09:32:47 PST
Date: Mon, 27 Feb 1989 9:32:42 PST
From: Gene H. Golub 415/723-3124 <golub@na-net.stanford.edu>
To: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Cc: tenured@score.stanford.edu, bureaucrat@polya.stanford.edu
Subject: Re: faculty meetings
In-Reply-To: Your message of Mon, 27 Feb 89 08:47:31 PDT
Message-Id: <CMM.0.88.604603962.golub@>
A regularly scheduled meeting every two weeks would be fine if it were
held at the same time and place and no "emergency" meetings were held.
Previously, there had been a place reserved in the teaching schedule
just for such purposes. By the way, the Computer Systems Colloquium
is held on Wednesdays at 4:15. It's an excellent series and you might
want to attend.
Gene
From @Score.Stanford.EDU:csl@sierra.STANFORD.EDU Fri Feb 24 16:31:20 1989
Flags: 000000000005
Return-Path: <@Score.Stanford.EDU:csl@sierra.STANFORD.EDU>
Received: from Score.Stanford.EDU by patience.stanford.edu (4.0/inc-1.5)
id AA00340; Fri, 24 Feb 89 16:31:17 PST
Received: from sierra.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Fri 24 Feb 89 15:52:01-PST
Received: by sierra.STANFORD.EDU (3.2/4.7); Fri, 24 Feb 89 15:49:14 PST
From: csl@sierra.STANFORD.EDU (Eileen Schwappach)
Date: Fri 24 Feb 89 15:49:12-PST
Subject: EE380 Colloquium, Wednesday, March 01, 1989
To: allcolloq@score
Message-Id: <604367352.0.CSL@SIERRA>
Mail-System-Version: <SUN-MM(219)+TOPSLIB(128)@SIERRA>
EE 380/CS 540 Computer Systems Colloquium
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Title: CAD Applications of Massive Parallel Computers
Speaker: Professor Alberto Sangiovanni-Vincentelli
From: UC Berkeley, Department of Electrical Engineering
Date: Wednesday, March 01, 1989 at 4:15 p.m.
Place: Terman Auditorium, Stanford University
ABSTRACT
Massively parallel computers such as the Connection Machine developed
by D. Hillis at MIT offer a new paradigm for CAD algorithms which allows
the exploitation of fine as well as coars grain parallelism. Two CPU
intensive CAD problems have been attacked with the Connection Machine:
process simulation and device simulation. As submicron geometries require
that simulations be performed in three dimensions, the computational
requirements increase dramatically. This talk will focus on the relationships
between algorithms and massively parallel architecture.
NOTE: The EE380 Colloquium is a public lecture which any interested
party may attend. In addition, after each talk there is an "informal
dutch-treat" dinner, organized by Professor Dennis Allison, which is
open to those attending the talk. If you plan to attend the dinner,
please R.S.V.P. to Professor Allison at Allison@SHASTA.Stanford.edu.
Please note that due to logistics, the number of persons to attend the
dinner may be limited.
-------
∂27-Feb-89 1005 GENESERETH@Score.Stanford.EDU Re: faculty meetings
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Feb 89 10:05:29 PST
Date: Mon 27 Feb 89 10:04:06-PST
From: Mike Genesereth <GENESERETH@Score.Stanford.EDU>
Subject: Re: faculty meetings
To: golub@patience.Stanford.EDU
cc: nilsson@Tenaya.Stanford.EDU, tenured@Score.Stanford.EDU,
bureaucrat@Polya.Stanford.EDU
In-Reply-To: <CMM.0.88.604603962.golub@>
Message-ID: <12474057449.33.GENESERETH@Score.Stanford.EDU>
Nils,
I stringly agree with Gene on this. Same time, same place. No meetings
outside. If all of these things I will guarantee to hold that
slot open.
mrg
-------
∂27-Feb-89 1009 @Score.Stanford.EDU:dill@amadeus.Stanford.EDU potluck
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Feb 89 10:08:56 PST
Received: from amadeus.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 27 Feb 89 10:06:04-PST
Received: by amadeus.Stanford.EDU (5.59/inc-1.0)
id AA25751; Mon, 27 Feb 89 10:05:11 PDT
Date: Mon, 27 Feb 89 10:05:11 PDT
From: dill@amadeus.Stanford.EDU (David Dill)
Message-Id: <8902271805.AA25751@amadeus.Stanford.EDU>
To: faculty@score.stanford.edu
Subject: potluck
The factor that pushed me over the brink was having to cook. I had a lot
to do last weekend, so it would have been difficult to find time to
attend (but feasible). I feel bad about punting these things, because
I strongly believe that the department needs more friendly interaction,
but it just didn't seem do-able.
By the way, not everyone has an account on Polya (which was needed for
the dish signup).
∂27-Feb-89 1045 @Score.Stanford.EDU:jcm@ra.stanford.edu potluck
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Feb 89 10:45:39 PST
Received: from ra.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 27 Feb 89 10:43:44-PST
Received: by ra.stanford.edu (5.59/25-eef) id AA04381; Mon, 27 Feb 89 10:42:35 PDT
Date: Mon, 27 Feb 89 10:42:35 PDT
From: John Mitchell <jcm@ra.stanford.edu>
Message-Id: <8902271842.AA04381@ra.stanford.edu>
To: faculty@score
Subject: potluck
I enjoyed the potluck. Among other things, I think it was a
far more pleasant setting for discussion than the usual TGIF.
Offhand, I would think one such event per quarter would be
about right. Some activity might make an afternoon more
enjoyable, although it is impossible to find an activity that
suits everyone. We used to have an MIT theory picnic with
football every year, even though there were fewer than 5
people who could catch/throw a football.
As far as "pot luck," there are plenty of places to buy food
that needs no further preparation.
John
∂27-Feb-89 1050 @Score.Stanford.EDU:winograd@loire.stanford.edu potluck
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Feb 89 10:50:01 PST
Received: from loire.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 27 Feb 89 10:44:01-PST
Received: by loire.stanford.edu (5.59/25-eef) id AA07362; Mon, 27 Feb 89 10:42:20 PDT
Date: Mon, 27 Feb 89 10:42:20 PDT
Message-Id: <8902271842.AA07362@loire.stanford.edu>
From: Terry Winograd <Winograd@csli.stanford.edu>
To: faculty@score.stanford.edu
Subject: potluck
I (as we all do) have individual reasons for missing the potluck -- we
had long ago purchased tickets for a benefit banquet for the Veterans
of the Abraham Lincoln Brigade -- but I think it rasises a more general
issue. Faculty are being exhorted to go as a favor (or obligation) to
the students. In other groups I have been connected with (e.g., CSLI)
the faculty go to events like this because they enjoy the chance to
talk with each other (as well as with the students). That's also one
reason they go to the colloquium (which nobody in this department does)
-- it provides an opportunity for informal contact.
As far as I can tell, the faculty in this department don't particularly
enjoy talking to each other, and therefore don't take advantage of
opportunities to do so. There are always good excuses, and it is
always good to lower the overhead to encourage those on the edge, but
overall that won't change things drastically. Maybe nothing will,
until the natural processes lead to a change in the makeup of the
faculty (I do have the feeling that the junior faculty have more group
interaction than the senior faculty).
Or maybe there are ways to shift the culture that we have drifted
into. Maybe the faculty retreat could be used to promote this. For
example, in the long run it might be better to have faculty members
talk about things that are important to them in their lives, rather
than about their technical work. I have to admit that for almost
everyone in the faculty, I know very little about what makes them tick
-- what they actually care about outside of their formal
academic/professional activities. I'm sure most of them have only the
vaguest idea about me in return.
I know this sounds California-groupy, and people will resent losing the
opportunity for "real" discussions of computer science. I happen to
believe that a small amount of time spent getting to see each other as
people will lead eventually to a much larger number of "real" technical
discussions at places like potlucks and colloquia.
--t
∂27-Feb-89 1100 TAJNAI@Score.Stanford.EDU Re: potluck
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Feb 89 11:00:34 PST
Date: Mon 27 Feb 89 10:57:51-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Re: potluck
To: jcm@ra.Stanford.EDU, faculty@Score.Stanford.EDU
In-Reply-To: <8902271842.AA04381@ra.stanford.edu>
Message-ID: <12474067235.20.TAJNAI@Score.Stanford.EDU>
Money that is spent on food for the CSD potluck is tax deductible if you
have enough business expenses to qualify. So buying pre-prepared food
saves time and energy and is economically reasonable.
Carolyn
-------
∂27-Feb-89 1106 TAJNAI@Score.Stanford.EDU Call for IBM fellowship nominees
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Feb 89 11:06:06 PST
Date: Mon 27 Feb 89 11:02:48-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: Call for IBM fellowship nominees
To: faculty@Score.Stanford.EDU
cc: hiller@Score.Stanford.EDU
Message-ID: <12474068137.20.TAJNAI@Score.Stanford.EDU>
The "call" from IBM should arrive this week. The deadline is March 24, so
I'm trying to get a head start.
We are invited to nominate 2 PHD students -- should be CSD, citizenship
not an issue. Also, should be an advanced student who has passed the
qual, and helpful if there are publications.
Carolyn
-------
∂27-Feb-89 1101 X3J13-mailer characters and conformance
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 27 Feb 89 11:00:39 PST
Date: Mon, 27 Feb 89 10:48:34 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890227.104834.baggins@almvma>
Subject: characters and conformance
>> See issues CONFORMANCE-POSITION and ERROR-TERMINOLOGY.
>> kc
Is a program written in non-STANDARD-CHAR-P characters conforming?
The conformance-position and error-terminology issues don't seem to
provide an answer. Clearly it is the case that portability of such
a program is restricted to implementations which support the
specific characters used (eg. the CLtL semi-standard chars, Kanji,
Hangul). Should all such programs be considered non-conforming?
Perhaps the terms "conforming" and "strictly conforming" (mentioned
in use by ANS C) could be used which also deal with programs written
using extra optional keyword arguments.
Conforming rules:
--basic rules as stated in CONFORMANCE-POSITION issue
Strictly Conforming rules:
--Conforming rules (above)
--Strictly conforming code is written using only
STANDARD-CHAR-P characters.
--Strictly conforming code is written using no extra
optional keyword arguments.
Perhaps Strictly Conforming is where one lumps together all the
requirements to define maximally portable code.
∂27-Feb-89 2357 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu LICS-89
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 27 Feb 89 23:57:02 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA19040; Mon, 27 Feb 89 23:54:50 -0800
Message-Id: <8902280754.AA19040@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Mon, 27 Feb 89 23:55:12 PST
Received: by BYUADMIN (Mailer R2.01A) id 2685; Tue, 28 Feb 89 00:51:10 MST
Date: Mon, 27 Feb 89 19:36:40 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Rohit Parikh <RIPBC@CUNYVM.CUNY.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Rohit Parikh <RIPBC@CUNYVM.CUNY.EDU>
Subject: LICS-89
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
FOURTH IEEE SYMPOSIUM ON LOGIC IN COMPUTER SCIENCE (LICS)
June 5-8, 1989
Asilomar, California
PROGRAM AND CONFERENCE INFORMATION
The Fourth IEEE Symposium on Logic in Computer Science will take
place at the Asilomar Conference Center in Pacific Grove, California,
from Monday June 5 to Thursday June 8, in 1989. The Symposium will
cover a wide range of theoretical and practical issues in computer
science that relate to logic in a broad sense. Below you will find
information about the location, travel arrangements, the conference,
and the program, as well as registration and room reservation forms.
PROGRAM COMMITTEE
M. Davis, M. Fitting, M. Hennessy, D. Israel, J. Jaffar, D. Joseph,
D. Kapur, D. Kfoury, P. Kolaitis, D. Kozen, V. Lifschitz, R. Parikh
(chair), A. Pnueli, V. Pratt, R. Statman.
ORGANIZING COMMITTEE
J. Barwise, W. Bledsoe, A. Chandra, E. Dijkstra, E. Engeler, J. Goguen,
D. Gries, Y. Gurevich, D. Kozen, Z. Manna, A. Meyer (chair), R. Parikh,
G. Plotkin, D. Scott.
LOCAL ARRANGEMENTS CHAIR
M. Abadi
Digital Equipment Corporation
Systems Research Center
130 Lytton Avenue
Palo Alto, CA 94301
USA
(415) 853-2196
internet: ma@src.dec.com
SPONSORSHIP
The 1989 LICS Symposium is sponsored by the Technical Committee on
Mathematical Foundations of Computing of the IEEE Computer Society, in
cooperation with the ACM Special Interest Group on Automata and
Computability Theory, the Association for Symbolic Logic, and the
European Association for Theoretical Computer Science. The Symposium
has been subsidized by a generous donation from Xerox PARC and by
further donations from the Digital Equipment Corporation Systems
Research Center, the Hewlett-Packard Research Laboratory, the
Laboratory for Computer Science of Edinburgh University, and IBM
(T.J. Watson Research Center and Almaden Research Center).
CONFERENCE PROGRAM
Sunday, June 4, 1989
Reception, 7:30pm-9:30pm
Monday, June 5, 1989
Session 1, 9am-noon
Chair: Dexter Kozen
9:00 Domains and Logics
Dana Scott (invited talk)
Coffee break, 10am-10:20am
10:20 Non-trivial Power Types Can't be Subtypes of Polymorphic Types
A. Pitts
10:45 Computational Lambda-Calculus and Monads
E. Moggi
11:10 Computing with Recursive Types
S. Cosmadakis
11:35 Stratified Polymorphism
D. Leivant
Lunch at noon
Session 2, 2pm-3:40pm
Chair: Phokion Kolaitis
2:00 Proof Theory and Semantics of Logic Programs
H. Gaifman and E. Shapiro
2:25 Negation as Refutation
M. Fitting
2:50 Fixpoint Extensions of First-order Logic and Datalog-like
Languages
S. Abiteboul and V. Vianu
3:15 Parthenon, a Parallel Theorem Prover for Non-Horn Clauses
S. Bose, E. Clarke, D. Long, and S. Michaylo
Coffee break, 3:40pm-4pm
Session 3, 4pm-5:40pm
Chair: David Israel
4:00 Type Inference for Record Concatenation and Multiple Inheritance
M. Wand
4:25 Computational Consequences and Partial Solutions of a Generalized
Unification Problem
A. Kfoury, J. Tiuryn, and P. Urzyczyn
4:50 How Complete is PER?
E. Robinson
5:15 Inheritance and Explicit Coercion
V. Breazu-Tannen, T. Coquand, C. Gunter, and A. Scedro
Session 4, 8pm-9pm
Chair: Vladimir Lifschitz
8 PM Emil Post's Contributions to Computer Science
Martin Davis (invited talk)
Tuesday, June 6, 1989
Session 5, 9am-noon
Chair: Vaughan Pratt
9:00 Towards Action-Refinement in Process Algebras
L. Aceto and M. Hennessy
9:25 A Complete Axiom System for Event Executions
J. Gischer
9:50 A Game-Theoretic Modelling of Concurrency
Y. Moschovakis
Coffee break, 10:15am-10:45am
10:45 Nets of Processes and Data Flow
A. Rabinovich and B. Trakhtenbrot
11:10 Axiomatizing Net Computations and Processes
P. Degano, J. Meseguer, and U. Montanari
11:35 A Probabilistic Powerdomain of Evaluations
C. Jones and G. Plotkin
Lunch at noon
Session 6, 2pm-3:40pm
Chair: Assaf Kfoury
2:00 Equality in Lazy Computation Systems
D. Howe
2:25 Extending the Lambda Calculus with Surjective Pairing is
Conservative
R. de Vrijer
2:50 Faithful Ideal Models for Recursive Polymorphic Types
M. Abadi, B. Pierce, and G. Plotkin
3:15 Structure and Representation in LF
R. Harper, D. Sannella, and A. Tarlecki
Visit to the Monterey Bay Aquarium, 7pm
(buses will be running between Asilomar and Monterey)
Wednesday, June 7, 1989
Session 7, 9am-noon
Chair: Rohit Parikh
9:00 The Mathematics of Nonmonotonic Reasoning
Vladimir Lifschitz (invited talk)
Coffee break, 10am-10:20am
10:20 On the Complexity of Epistemic Reasoning
M. Vardi
10:45 RI: A Logic for Reasoning with Inconsistency
M. Kifer and E. Lozinskii
11:10 Non-well-founded Sets Obtained from Ideal Fixed Points
M. Mislove, L. Moss, and F. Oles
11:35 Substitutional Recursion on Non-well-founded Sets
T. Fernando
Lunch at noon
Session 8, 2pm-3:40pm
Chair: Joxan Jaffar
2:00 A Sound and Complete Axiomatization of Operational Equivalence of
Programs with Memory
I. Mason and C. Talcott
2:25 A Fully Abstract Semantics for a Functional Language with Logic
Variables
R. Jagadeesan, P. Panangaden, and K. Pingali
2:50 Unified Algebras and Institutions
P. Mosses
3:15 Elf: A Language for Logic Definition and Verified Metaprogramming
F. Pfenning
Coffee break, 3:40pm-4pm
Session 9, 4pm-5:40pm
Chair: Melvin Fitting
4:00 Some Complexity Bounds for Dynamic Logic
A. Stolboushkin
4:25 On Simultaneously Determinizing and Complementing omega-Automata
A. Emerson and C. Jutla
4:50 mu-Definable Sets of Integers
R. Lubarsky
5:15 Compositional Model Checking
E. Clarke, D. Long, and K. McMillan
Business meeting, 8pm
Thursday, June 8, 1989
Session 10, 9am-10:40am
Chair: Martin Davis
9:00 Characterizing Complexity Classes by Higher Type Primitive
Recursive Definitions
A. Goerdt
9:25 Polynomially Graded Logic
A. Nerode, J. Remmel, and A. Scedro
9:50 ECC, an Extended Calculus of Constructions
Z. Luo
10:15 A Sufficient Condition for the Termination of the Direct Sum of
Term Rewriting Systems
A. Middeldorp
Lunch at noon
Conference Ends
CONFERENCE EVENTS
Sunday: an opening reception at Asilomar, at 7:30pm.
Tuesday: a visit to the Monterey Bay Aquarium, with copious drinks and
hors d'oeuvres, starting at 7pm; buses will be running between Asilomar
and downtown Monterey for the evening.
Wednesday: a barbecue at Asilomar at 6pm (weather permitting) and a
business meeting at 8pm.
LOCATION
Asilomar is situated on the tip of the Monterey Peninsula, overlooking
the Pacific Ocean, 120 miles south of San Francisco. Asilomar occupies
105 secluded acres of forest and dune, with pleasant pathways, a
swimming pool, and an exercise trail. Just over the dunes, Asilomar
State Beach stretches for over a mile. Monterey is an interesting
historical city--by California standards. Nearby, Carmel and Big Sur
offer quaint towns, pleasant beaches, and a rugged coastline. The
weather is mild, with temperatures in the 60's and 70's and a slight
chance of rain; the evenings can be cool, and we recommend bringing a
jacket.
TRANSPORTATION TO ASILOMAR
The following information held in January 1989.
Flying into Monterey:
This is the simplest way to reach Asilomar. United, SkyWest, USAir,
American Eagle, and others fly to Monterey from West Coast locations,
such as San Francisco and Los Angeles. A shuttle goes from the
Monterey airport to Asilomar, for $8.
Flying into San Jose or San Francisco:
If you fly into San Jose or San Francisco, we recommend you rent a
car. You may wish to share a car rental. We can provide you with a
list of other registrants whom you may contact about such sharing
arrangements. The San Jose airport is about one and a half hours away
from Monterey by car. The San Francisco airport is about two and half
hours away by car. In both cases, leave the airport on Highway 101
South and follow the driving directions below.
Public transportation is a cheaper but inconvenient alternative.
Greyhound buses go from the San Francisco airport to Monterey five
times per day, at 8:40am, 10:55am, 3:25pm, 7:10pm, and 10pm. The trip
lasts between three and four hours and costs $15. Asilomar can be
reached from the Greyhound station with a short cab ride or on local
buses.
Driving to Asilomar:
When arriving on Highway 101, turn west at Salinas onto Highway 68 and
proceed to the Asilomar gatepost at the end of the highway. When using
Route 1, turn west onto Highway 68 in Carmel, and proceed as above.
ACCOMMODATIONS
Accommodations are at Asilomar; the standard arrangement is room and
board from Sunday at 3pm to Thursday at noon. All meals are included,
from dinner on Sunday through lunch on Thursday. If you prefer
vegetarian meals, please indicate this preference on the room
reservation form. If you wish to spend other nights in the area,
Asilomar will attempt to provide accommodations or suggest suitable
hotels. Should you have any questions, you can contact Asilomar
directly at the address given on the reservation form or by phone at
(408) 372-8016.
Room availability is limited. WE URGE YOU TO REGISTER EARLY.
REGISTRATION AND ROOM RESERVATION
Please send the registration form and the room reservation form to the
addresses given, each with a corresponding check for the exact amount
in US dollars, by APRIL 26. Once they have both been received,
Asilomar will send you an acknowledgement letter. Cancellations after
May 4 are subject to $25 charges, both from Asilomar and from LICS.
After May 20, they are subject to forfeiture of all fees.
LICS REGISTRATION FORM
Please send this form--along with a check payable to the 4th Symposium
on Logic in Computer Science--to
Martin Abadi
Digital Equipment Corporation
Systems Research Center
130 Lytton Avenue
Palo Alto, CA 94301
USA
(Attn. LICS registration)
Type or print:
Name_________________________________________________________________
Affiliation__________________________________________________________
Street Address_______________________________________________________
City________________________ State______________________ Zip_________
Country______________________________________ Phone__________________
E-mail_______________________________________________________________
Before April 26 After April 26
Member or author $150 $210
Non-member $210 $270
Full-time student $50 $75
Registration fees include conference proceedings, the opening
reception, and the Aquarium excursion. The member or author rate is
for members of the IEEE Computer Society, the ACM, the EATCS, the ASL,
the program committee, and the organizing committee, and for authors
of presented papers. If you qualify for the rate, please indicate
how:______________________________
LICS ROOM RESERVATION FORM
Please send one form per person--along with a check payable to
Asilomar Conference Center--to
Asilomar Conference Center
Post Office Box 537
Pacific Grove, CA 93950
USA
For additional information, call Asilomar at (408) 372-8016. Type or
print:
Name_________________________________________________________________
Street Address_______________________________________________________
City________________________ State______________________ Zip_________
Country______________________________________ Phone__________________
Check which kind of accommodation you would like to reserve. You may
indicate first and second choices:
Single Double 3/4-room Youth (2--17yrs.)
Deluxe $380 $220 $200 $135
Historic $240 $200 $200 $135
Rustic $220 $180 $180 $135
In historic and rustic rooms, the youth rate applies with one adult or
at least two children per room; in deluxe rooms, it applies with two
adults per room. Please indicate age of children________________
____ Male ____ Female ____ Smoker ____ Non-smoker
____ Vegetarian
____ Pick me a roommate. ____ I'll room with_______________________.
∂28-Feb-89 0733 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Today's Faculty Lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Feb 89 07:33:40 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 28 Feb 89 07:31:53-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA24742; Tue, 28 Feb 89 07:30:27 -0800
Date: Tue, 28 Feb 1989 7:30:25 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, bureaucrats@score, staff-rep@score
Subject: Today's Faculty Lunch
Message-Id: <CMM.0.87.604683025.chandler@polya.stanford.edu>
Just to remind you ... Steve Jobs from NeXT will be our guest today at the
faculty lunch....MJH-146 at 12:15.
∂28-Feb-89 0816 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu The ?What Exit? seminar series
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Feb 89 08:16:34 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA25909; Tue, 28 Feb 89 08:14:14 -0800
Message-Id: <8902281614.AA25909@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Tue, 28 Feb 89 08:14:38 PST
Received: by BYUADMIN (Mailer R2.01A) id 6731; Tue, 28 Feb 89 09:12:11 MST
Date: Tue, 28 Feb 89 09:58:25 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Joan Feigenbaum <jf@RESEARCH.ATT.COM>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Joan Feigenbaum <jf@RESEARCH.ATT.COM>
Subject: The ?What Exit? seminar series
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
This is the final announcement of the first meeting of
THE ?WHAT EXIT? SEMINAR SERIES,
sponsored by DIMACS, the new NSF Science and Technology Center
for DIscrete MAth and Computer Science.
Tentatively, we are planning to sponsor a series of
day-long seminars, each organized around a specific topic
in discrete math or theoretical computer science. The
participating institutions are Rutgers, Princeton, Bellcore,
and AT&T Bell Labs, and the location of the meetings will
rotate among these four. The first seminar will take place
at Princeton.
*****************************************************************
Topic: Approximation Algorithms for NP-Complete Problems
Date: Friday, March 3, 1989
Time of first talk: 10:30 a.m.
Location: Princeton
Talks:
(1) Ravi Kannan (CMU):
Sampling from a Convex Set and Volume Computation
This talk will describe a random polynomial-time algorithm that
finds the volume of any convex set to any desired degree of
accuracy. The algorithm uses a random walk to pick a point in a
convex set with nearly uniform distribution. It will be easy to
see that the steady state distribution of the Markov chain is
uniform; the bulk of the effort is spent in proving that the Marko
chain "mixes rapidly", i.e., approaches the steady state
distribuition in a polynomial number of steps. This is done using
some recent results on isoperimetry for general Reimannian
manifolds.
This is joint work with M. Dyer and A. Frieze.
(2) David Shmoys (MIT):
Using Linear Programming in the Design and Analysis of
Approximation Algorithms
One of the oldest heuristics for solving hard combinatorial
optimization problems is as follows: formulate the problem
as an integer program, solve the linear relaxation, and then
round the solution to a nearby integer solution. Alternatively,
linear programming may be used to analyze the performance of
more combinatorially defined procedures, by relating the solution
value delivered by the procedure to the value of the linear programming
relaxation, in addition to proving a result relating the integer
and fractional optima.
We will give an example of both types of results, as applied
to approximating (1) a certain scheduling problem within a fixed bound,
and (2) the traveling salesman problem with triangle inequality.
This is joint work with Jan Karel Lenstra, Eva Tardos and David
Williamson.
(3) Mihalis Yannakakis (AT&T-Bell Labs):
Approximation and Complexity Classes
There is a number of common optimization problems
which can be approximated easily with some constant ratio,
but for which it has proved very difficult to go
beyond it and either find a polynomial-time
approximation scheme or show that none exists.
We define some classes which contain problems of this type.
Several natural problems are complete under a kind
of reduction that preserves approximability.
Such a complete problem has a polynomial-time approximation
scheme iff the whole class does.
________________________________________________________________
Directions:
Park in Lot 21, which you reach as follows: Assume you start
on Nassau Street (a.k.a. Rt. 27) going southwest (i.e., away from
New Brunswick, towards Trenton). Turn left on Washington Road
(at a light). Drive on Washington past Fine Hall and Palmer
Stadium. Turn left onto Faculty Road (at a light). If you
get to a bridge, you have gone too far. The first real street
onto which you can turn left off Faculty is Fitzrandolf. (There
is a previous left, but it is into an alley as opposed to a real
street.) Take that left, and Lot 21 is on your left.
The talks will take place in the Woodrow Wilson School, on the
corner of Washington Street and Prospect Avenue. To get there
from Lot 21, go back to Fitzrandolf and walk in the same direction
in which you were driving before you entered the lot. Go left
on Prospect and continue until Washington. The Woodrow Wilson
School is a large white building.
It takes 10 to 15 minutes to walk from Lot 21 to the Woodrow
Wilson School. So allow enough time!
∂28-Feb-89 0854 @Score.Stanford.EDU:nilsson@Tenaya.stanford.edu fac mtg
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Feb 89 08:54:30 PST
Received: from Tenaya.stanford.edu by SCORE.STANFORD.EDU with TCP; Tue 28 Feb 89 08:53:07-PST
Received: by Tenaya.stanford.edu (5.59/25-eef) id AA13310; Tue, 28 Feb 89 08:49:39 PDT
Date: Tue, 28 Feb 89 08:49:39 PDT
From: Nils Nilsson <nilsson@Tenaya.stanford.edu>
Message-Id: <8902281649.AA13310@Tenaya.stanford.edu>
To: tenured@score
Cc: bureaucrat@polya
Subject: fac mtg
I think the best way to handle our two faculty meetings is to try to
combine them and have just one meeting tomorrow, Wednesday, March 1 at
4:15 promptly. I apologize to those who want to attend the systems
seminar. The faculty meeting will begin with all associate and full
professors only (plus student representatives). We will consider the
case of Mike Clancy's appt as an assoc professor (teaching). George
Wheaton, chair of the committee that found Clancy, will present
the case briefly, but please do read the letters we have on Clancy.
Next, we will excuse the assoc profs, and move smartly on to consider
a promotion case previously mentioned to the full professors. Jeff
Ullman (who will be taking just one day off from his sabbatical at
Princeton to visit Stanford on March 1) will present the case. (That's
why we are having this meeting on a Wednesday instead of on our
regular Tuesday time slot.)
I realize that some will not be able to make this meeting (e.g. Terry
Winograd has a previously scheduled under-graduate committee meeting
at that time). For those who cannot attend, please:
1) read the letters on the candidates
2) talk to those who did attend
3) give Betty Scott your vote
(Since the Clancy appt impacts strongly on undergraduate matters,
perhaps the u.g. committee might want to take a few minutes during
their meeting to consider the Clancy case and the letters on him and
then communicate their vote to Betty Scott.)
Thanks for your patience with this very important aspect of our
departmental life. We will be featuring cookies at the meeting!
-Nils
∂28-Feb-89 0956 X3J13-mailer agenda items, registration
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 28 Feb 89 09:56:46 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA01016g; Tue, 28 Feb 89 09:50:16 PST
Received: by challenger id AA15462g; Tue, 28 Feb 89 09:45:48 PST
Date: Tue, 28 Feb 89 09:45:48 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8902281745.AA15462@challenger>
To: x3j13@sail.stanford.edu
Subject: agenda items, registration
Let me know if you have anything to add to the March agenda, how much time
you'll need and what day you'd prefer. I'll be away the week before the X3J13
meeting so please let me know by March 15.
If you have anything to be voted on, please mail documents by March 6 to avoid
the two week rule.
Please let me know of any changes to the registration list below.
X3J13 Attendee Information
02/28/89
Name Institute Paid L1 L2 L3
David Bartley TI -0- y y y
Paul Beiser HP -0- y y y
Mary Boelk Johnson Controls, Inc. -0- y y y
Kathy Chapman DEC -0- - - -
Jeff Dalton University of Ediburgh -0- y y y
Patrick Dussud Lucid, Inc. -0- y y y
Dick Gabriel Lucid, Inc. -0- y y y
David Gray TI -0- y y y
George Hadden Honeywell S&RC -0- y y y
Masayuki Ida Aoyama Gakuin University -0- y y y
Gregor Kiczales Xerox Corp. -0- y y y
Aaron Larson Honeywell S&RC -0- y y y
Kevin Layer Franz, Inc. 50.00 y y y
Thom Linden IBM 50.00 y y y
David Loeffler MCC -0- y y y
Sandra Loosemore University of Utah -0- y y y
Barry Margolin Thinking Machines -0- y y y
Bob Mathis CONTEL -0- y y y
David Moon Symbolics -0- y y y
Cris Perdue Sun Microsystems -0- y y y
Dan Pierson Encore Computer -0- y y y
Kent Pitman Symbolics -0- y y y
Guy Steele Thinking Machines -0- y y y
Walter van Roggen DEC -0- y y y
JonL White Lucid, Inc. -0- y y y
Jan Zubkoff Lucid, Inc. -0- y y y
∂28-Feb-89 1128 misha@polya.Stanford.EDU reminder: AFLB TODAY!
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Feb 89 11:28:22 PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA05518; Tue, 28 Feb 89 11:24:59 -0800
Date: Tue, 28 Feb 89 11:24:59 -0800
From: Michael Kharitonov <misha@polya.Stanford.EDU>
Message-Id: <8902281924.AA05518@polya.Stanford.EDU>
To: aflb-all@polya.Stanford.EDU
Subject: reminder: AFLB TODAY!
Next AFLB will be TODAY, February 28, 4:15pm
in the usual room. The talk will be by Serge Plotkin from Stanford:
SUBLINEAR-TIME PARALLEL ALGORITHMS FOR MATCHING AND RELATED PROBLEMS
Serge Plotkin
We present the first sublinear-time deterministic parallel algorithms for
bipartite matching and several related problems, including maximal
node-disjoint paths, depth-first search, and flows in zero-one networks. Our
results are based on a better understanding of the combinatorial structure of
the above problems, which leads to new algorithmic techniques. In particular,
we show how to use maximal matching to extend, in parallel, a current set of
node-disjoint paths and how to take advantage of the parallelism that arises
when a large number of nodes are ``active'' during an execution of a
push/relabel network flow algorithm.
We also show how to apply our techniques to design parallel algorithms for the
weighted versions of the above problems. In particular, we present
sublinear-time deterministic parallel algorithms for finding a minimum-weight
bipartite matching and for finding a minimum-cost flow in a network with
zero-one capacities, if the weights are polynomially bounded integers.
Joint work with A. Goldberg and P. Vaidya.
∂28-Feb-89 1347 X3J13-mailer cs proposal
Received: from IBM.COM ([192.5.58.7]) by SAIL.Stanford.EDU with TCP; 28 Feb 89 13:46:58 PST
Date: Tue, 28 Feb 89 12:46:45 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890228.124645.baggins@almvma>
Subject: cs proposal
I'll be away from the office next week (6-9 March) and won't
be able to respond to any comments on the proposal before
13 March. I've received one straw vote response todate.
∂01-Mar-89 0611 @Score.Stanford.EDU:op@polya.Stanford.EDU The rec.humor.funny controversy
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 89 06:11:14 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 1 Mar 89 06:08:14-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA06224; Wed, 1 Mar 89 06:06:21 -0800
From: Oren Patashnik <op@polya.Stanford.EDU>
Sender: Oren Patashnik <op@polya.stanford.edu>
Date: Wed, 1 Mar 1989 6:06:19 PST
To: hk.dxk@forsythe, HK.GRH@Forsythe, s.street@macbeth, gq.vvn@forsythe,
g.gorin@macbeth, hk.ixb@forsythe, hk.jjs@forsythe, siegman@sierra,
cr.apc@forsythe, faculty@score, su-etc@score
Subject: The rec.humor.funny controversy
Reply-To: op@polya.stanford.edu
Message-Id: <CMM.0.88.604764379.op@polya.stanford.edu>
The students of the Computer Science Department passed the resolution
below by a vote of 128 to 4, conducted via electronic mail on February
27th and 28th, with the identities of the voters kept confidential.
The vote totals represent about 50% of all PhD students, 20% of all
Master's students, and 20% of all undergraduate majors in the
department. Three of the four dissenting voters thought that the
rec.humor.funny newsgroup should not be reinstated. Several other
students chose not to vote because, although they agreed that
rec.humor.funny should be reinstated, they couldn't support other
parts of the resolution. About 20 of the "ayes" agreed with the
resolution as passed, but would have preferred it to include a summary
of the rebuttals of AIR's arguments for the removal of rec.humor.funny;
those rebuttals appeared on the su.etc newsgroup. And we have no way
of estimating how many students didn't see the proposed resolution
in time to vote on it. Here's the resolution.
----------------------------------------------------------------------
A CALL FOR THE FREE EXCHANGE OF IDEAS
Since we students in the Computer Science Department are, as a group,
the segment of the Stanford community most familiar with the
"newsgroup" medium, we have a responsibility to comment on the
controversy.
In the short term we have little at stake in the removal from AIR
computers of rec.humor.funny, since that newsgroup remains uncensored
on our department's computers. But in the long term we have much at
stake, for the newsgroups constitute an increasingly important source
of information and means of communication; any administrative attempts
to limit the ideas they contain pose a threat to academic freedom.
We find it particularly distressing that an institution so committed
to the free exchange of ideas should resort to suppressing them.
The issue that sparked the present controversy was offensive speech.
We believe that each of us must be sensitive to the feelings of
others, whether we express ourselves through the newsgroups or over
the phone or face to face. Inevitably, however, where there is free
speech, someone will take offense. Yet the newsgroups provide a
uniquely effective forum for rebutting offensive speech. The su.etc
newsgroup, for instance, has a history of showering the wrath of an
outraged readership onto transgressors of accepted community standards.
Offensive thoughts, ultimately, are best squelched by their failure to
survive in the marketplace of ideas.
We believe that AIR and SDC should reinstate rec.humor.funny.
∂01-Mar-89 0758 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Today's Faculty Meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 89 07:58:00 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 1 Mar 89 07:56:50-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA08121; Wed, 1 Mar 89 07:55:24 -0800
Date: Wed, 1 Mar 1989 7:55:21 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: tenured@score
Cc: bureaucrats@polya
Subject: Today's Faculty Meeting
Message-Id: <CMM.0.87.604770921.chandler@polya.stanford.edu>
I sent out a message yesterday announcing that the faculty meeting would be
held today at 2:30 in MJH-146. That information was incorrect.
Today's faculty meeting will be held at 2:30 in MJH-220. Sorry for the
confusion.
∂01-Mar-89 0802 @Score.Stanford.EDU:chandler@polya.Stanford.EDU I can't believe I did that.....
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 89 08:02:48 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 1 Mar 89 08:01:40-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA08203; Wed, 1 Mar 89 08:00:15 -0800
Date: Wed, 1 Mar 1989 8:00:13 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: tenured@score
Cc: bureaucrats@polya
Subject: I can't believe I did that.....
Message-Id: <CMM.0.87.604771213.chandler@polya.stanford.edu>
Now that I've given you the correct location, I've given you the incorrect
time. Not 2:30...........but 4:15.
∂01-Mar-89 1109 X3J13-mailer Section 1.7
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 11:09:32 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA00298; Wed, 1 Mar 89 11:07:25 PST
Message-Id: <8903011907.AA00298@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA00298; Wed, 1 Mar 89 11:07:25 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:23
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 1.7
%%Language Extensions
[{\it This section is dependent upon the passage or failure of the following
issues: EXTENSIONS-POSITION, EXTRA-SYNTAX, EXTRA-OPTIONAL-KEYWORD-ARGUMENTS,
UNSPECIFIED-DATATYPTES, UNSOLICITED-MESSAGES, MACRO-AS-FUNCTION, and
EXTRA-RETURN-VALUES. When they have passed or failed, this section
will be altered.}]
A language extension is
any implementation-supplied {\word tool} that isn't explicitly defined
in this standard. This includes facilities added to {\word tools} defined
in this standard.
An implementation may have extensions,
provided they do not alter the behavior of conforming code and
provided they are not explicitly prohibited by this standard.
From Common Lisp's point of view, defining an extension
refers to a facility's initial definition.
Whether an implementation permits redefinition of an extension is between that
implementation and its users and beyond the scope of this standard to
specify.
If this standard says that ``the results are unspecified", and an
implementation specifies the results, this an extension in the
sense that if the correct behavior of a program depends on the results,
only implementations with the same extension will execute the program
correctly.
In places where the standard says that ``an implementation may be extended",
this implies that a conforming, but probably non-portable, program can
be written using the implementation's extension.
%Following will be included if the proposal that states this is passed.
%An implementation is required to have a way to disable its extensions, so
%that a programmer can be told when he is using a feature that might
%affect his program's portability.
The following list contains specific guidance to implentations
concerning certain types of extensions.
\beginlist
\itemitem{\bf Additional syntax}
An implementation
is not allowed to extend {\word macros} and {\word special forms} to take
additional syntax not specified in this standard.
\itemitem{\bf Extra optional or named arguments}
Unless explicitly allowed in this standard,
implementations are not allowed to include definitions
of {\word functions} with extra optional or named arguments
with system-dependent meanings.
When extra optional or named arguments are allowed by this
standard, they will be annotated as follows:
{\word functions} that may be
extended to take implementation-specific optional arguments are indicated
by {\tt &rest ignore} in their argument list.
{\word Functions} that may be extended
to take additional keyword parameters are indicated by {\tt &allow-other-keys}.
The goal is not to outlaw any extensions currently offered by
implementors, but to make the range of extensions to {\word functions}
defined in
this standard well documented in this standard. Implementations that want to
extend {\word functions} that aren't explicitly
allowed to be extended can instead
shadow them.
% or as follows, if this proposal passes.
%Alternate proposal: NOT-IN-STANDARD-PACKAGE
%
%Like NO-EXCEPT-AS-ALLOWED, except that an implementation may always
%provide additional named arguments to a function if the names are not in
%an implementation-specific package (the list of these currently includes
%the LISP, USER, and KEYWORD packages).
%
\itemitem{\bf Extra return values}
Unless it is explicitly allowed in this standard,
an implementation is
not allowed to return extra values from {\word functions}
defined by this standard.
\itemitem{\bf Function behavior on non-standard data types}
An implementation does not define the behavior of {\word functions}
on data types not explicitly permitted by this standard.
\itemitem{\bf Unsolicited messages}
Unsolicited messages, such as garbage collector notifications
and autoload heralds, if
they are produced by an implementation, should not be directed to
@var[standard-output] or @var[error-output]\rm.
If an implementation produces them, they
may be produced on a {\datatype stream}
that is not shared with any of the {\datatype streams}
that a user might redefine or redirect. This means that an
implementation is allowed to
direct such notifications to @var[terminal-io] since a user may not redirect
@var[terminal-io]\rm.
Messages such as progress reports from {\function load} and
{\function compile} are solicited,
and are not covered here.
\itemitem{\bf Implementation of macros and special forms}
Operators that are defined as {\word macros} or
{\word special forms} may be defined as {\word
functions}
instead if the semantics can be preserved.
%or as follows:
%Alternate Proposal: MACRO-AS-FUNCTION:STATUS-QUO
%
%The standard will remain silent on the issue of whether or not is
%is legal for an implementation to implemention "macros" and
%"special forms" as functions.
%or as follows:
%Alternate Proposal: MACRO-AS-FUNCTION:DISALLOW
%
%A conforming implementation does not define "macros" and "special forms"
%as functions.
\endlist
∂01-Mar-89 1111 X3J13-mailer Section 5.2
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 11:10:51 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA00392; Wed, 1 Mar 89 11:08:46 PST
Message-Id: <8903011908.AA00392@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA00392; Wed, 1 Mar 89 11:08:46 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:25
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 5.2
%% Input/Output
It is possible to perform I/O to any device physically connected to
the machine on which the @xlisp\ system is running.
Some implementations, however, may not support the interfaces
to all possible physical devices. Some external
data sources
are treated specially in @clisp. The following sections describe the file
system interface, binary and character I/O, and the {\function load}ing process.
\beginsubSection{Files}
%% 23.0.0 5
@clisp\ assumes that files are named, that given a name a
{\datatype stream} can be constructed that
connects to a file of that name, and that the
names can be fit into a {\datatype pathname}.
%% 23.0.0 6
%Facilities are provided for manipulating {\datatype pathnames},
%for creating
%{\datatype streams}
%connected to files, and for manipulating the file system
%through {\datatype pathnames} and {\datatype streams}.
%Left out.
%% 23.1.0 1
In general, different
file systems have different naming formats for files.
There are two ways to represent file names:
namestrings, which are {\datatype strings}
in the implementation-dependent form
customary for the file system, and {\datatype pathnames}, which are
{\word objects} that represent file names in an implementation-independent
way. {\word Functions}
are provided to convert between these two representations,
and all manipulations of files can be expressed in machine-independent
terms by using {\datatype pathnames}. See ``Pathname''.
%% 23.1.0 2
%In order to allow code to operate in a network environment
%that may have more than one kind of file system, the pathname facility
%allows a file name to specify which file system (called the
%host) is to be used.
%Left out.
%%% 23.1.1 11
%Parsing is the conversion of a namestring
%into a {\datatype pathname}. This operation is
%implementation-dependent, because the format of namestrings
%is implementation-dependent.
%
%Merging takes a {\datatype pathname} with missing components
%and supplies values for those components from a source of defaults.
%This operation is also implementation-dependent because the
%set of valid {\datatype pathnames} that may result from merging is
%implementation-dependent.
%% 23.2.0 1
The basic operations for opening a file are {\function open} and
{\function with-open-file}. The basic operation for closing a file
is {\function close}.
Rules concerning file I/O follow:
\beginlist
%% 22.2.1 2
\itemitem{\bf Eof-error-p}
{\arg Eof-error-p} in I/O {\word forms}
controls what happens if input is from a file (or any other
input source that has a definite end) and the end of the file is reached.
If {\arg eof-error-p} is true (the default), an error will be signalled
at end of file. If it is false, then no error is signalled, and instead
the {\word form} returns {\arg eof-value}.
%% 22.2.1 4
\itemitem{\bf Recursive-p}
If {\arg recursive-p} is
supplied and not @nil\rm, it specifies that
this {\word form}
call is not a {\word top level} call to {\function read} but an embedded call,
typically from the {\word function} for a macro character.
It is important to distinguish such recursive calls for three reasons.
%% 22.2.1 5
\beginlist
\itemitem{1.}
A {\word top level} call establishes the context within which the
{\tt \#n=} and {\tt \#n\#} syntax is scoped. Consider, for example,
the expression
@lisp
(cons '#3=(p q r) '(x y . #3#))
@endlisp
If the single quote macro character were defined in this way:
@lisp
(set-macro-character #@bsl\ '
#'(lambda (stream char)
(declare (ignore char))
(list 'quote (read stream))))
@endlisp
then the expression could not be read properly, because there would be no way
to know when {\function read} is called recursively by the first
occurrence of @f['] that the label @f[\#3=] would be referred to
later in the containing expression.
There would be no way to know because {\function read}
could not determine that it was called by a macro character function
rather than from {\word top level}. The correct way to define the single quote
macro character uses {\arg recursive-p}:
@lisp
(set-macro-character #@bsl\ '
#'(lambda (stream char)
(declare (ignore char))
(list 'quote (read stream t nil t))))
@endlisp
%% 22.2.1 6
\itemitem{2.}
A recursive call does not alter whether the reading process
is to preserve whitespace or not (as determined by whether the
{\word top level} call was to {\function read} or {\function
read-preserving-whitespace}).
Suppose again that single-quote had the first, incorrect, macro character
definition shown above. Then a call to {\function read-preserving-whitespace}
that read the expression @f['foo ] would fail to preserve the space
character following the symbol @f[foo] because the single-quote
macro character function calls {\function read},
not {\function read-preserving-whitespace},
to read the following expression (in this case @f[foo]\rm).
The correct definition, which passes the value @true\ for {\arg recursive-p}
to {\function read}, allows the {\word top level} call to determine
whether whitespace is preserved.
%% 22.2.1 8
\itemitem{3.}
When end-of-file is encountered and the {\arg eof-error-p} argument
is not @nil\rm, the kind of error that is signalled may depend on the value
of {\arg recursive-p}. If {\arg recursive-p}
is not @nil\rm, then the end-of-file
is deemed to have occurred within the middle of a printed representation;
if {\arg recursive-p} is @nil\rm, then the end-of-file may be deemed to have
occurred between {\word objects} rather than within the middle of one.
\endlist
\endlist
\endsubSection%{Files}
\beginsubSection{Character and Binary Input/Output}
Figure {\chapno--\the\capno} lists reader and printer control variables.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
@var[read-base] & @var[read-suppress] & @var[print-escape] \cr
@var[print-pretty] & @var[print-circle] & @var[print-base] \cr
@var[print-radix] & @var[print-case] & @var[print-gensym] \cr
@var[print-level] & @var[print-length] & @var[print-array] \cr
@var[read-default-float-format] & & \cr
\noalign{\vskip -9pt} }}
\caption{Reader and printer control variables}
\endfig
Figure {\chapno--\the\capno} lists character and binary input
stream {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt read }&{\tt read-preserving-whitespace }&{\tt read-delimited-list }\cr
{\tt read-line }&{\tt read-char }&{\tt unread-char }\cr
{\tt peek-char }&{\tt listen }&{\tt read-char-no-hang }\cr
{\tt clear-input }&{\tt read-from-string }&{\tt parse-integer }\cr
{\tt read-byte }&{\tt }&{\tt }\cr
\noalign{\vskip -9pt} }}
\caption{Character and binary input tools}
\endfig
Figure {\chapno--\the\capno} lists character and binary output
stream {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt write }&{\tt prin1 }&{\tt print }\cr
{\tt pprint }&{\tt princ }&{\tt write-to-string }\cr
{\tt prin1-to-string }&{\tt princ-to-string }&{\tt write-char }\cr
{\tt write-string }&{\tt write-line }&{\tt terpri }\cr
{\tt fresh-line }&{\tt finish-output }&{\tt force-output }\cr
{\tt clear-output }&{\tt write-byte }&{\tt format }\cr
\noalign{\vskip -9pt} }}
\caption{Character and binary output tools}
\endfig
{\function y-or-n-p} and
{\function yes-or-no-p} are used to query the user.
%% 2.2.2 6
When the character {\tt \#{\char '134}Newline} is written to an output file,
the implementation must take the appropriate action
to produce a line division. This might involve writing out a
record or translating {\tt \#{\char '134}Newline} to a CR/LF sequence.
\endsubSection%{Character and Binary Input/Output}
\beginsubSection{Loading}
%% 23.4.0 1
To {\function load} a file is to treat its contents as code and execute
that code. The file may contain character data or binary data. If it is
charater data, {\function load}ing
is accomplished essentially by sequentially reading
the {\word forms} in the file, evaluating each immediately after it is read.
%% 23.4.0 2
{\function Load}ing a compiled
(``fasload'') file is similar, except that the file does not
contain text but rather pre-digested expressions created by the
compiler that can be {\function load}ed more quickly.
See ``Compilation''.
\endsubSection%{Loading}
∂01-Mar-89 1136 X3J13-mailer Section 1.5
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 11:36:49 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA02677; Wed, 1 Mar 89 11:34:49 PST
Message-Id: <8903011934.AA02677@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA02677; Wed, 1 Mar 89 11:34:49 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:23
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 1.5
%%Compliance
[{\it If the issue, CONFORMANCE-POSITION, undergoes radical modification
before passage, this section will change. Therefore, passage of this
section and CONFORMANCE-POSITION go hand in hand.}]
A conformity clause is a statement that is not part of
the language definition, but specifies requirements for compliance with the
language standard.
The standard presents the syntax and semantics to be implemented by
a conforming implementation.
A conforming implementation is an implementation
that processes
code that is written
in the language defined by the language standard, and
that obeys all the conformity clauses for
implementations written in the language standard.
Requirements for a conforming implementation:
\beginlist
\itemitem{1.} A conforming implementation is one that correctly
translates and executes conforming code.
\itemitem{2.} A conforming implementation
is one that rejects all
code that contains errors whose detection is required by this standard.
\itemitem{3.} A conforming implementation is one that contains no
variation except where the language standard permits, and specifies all
such permitted variations in the manner prescribed by this standard.
See ``Language Extensions''.
\itemitem{4.} A conforming implementation includes the following
in its accompanying documentation:
\beginlist
\itemitem{a.} A list of all definitions or values for the
implementation-defined features in the standard language.
See ``Implementation-defined Features''.
\itemitem{b.} A list of all the features of this implementation
which are not part of the standard language but which could unexpectedly
interact with user code, including all package names
and nicknames the implementation
uses.
\itemitem{c.} A statement of conformity, giving the complete reference to
this standard.
\endlist
\itemitem{5.} A conforming implementation shall meet the technical
specification in its accompanying documentation when related to the
requirements of this standard.
\itemitem{6.} A conforming implementation shall treat an
error as is outlined in ``Errors''.
\endlist
The basic test for conformance will be that code written to the letter
of the standard will run in all conforming implementations.
The basic rules are as follows:
\beginlist
\itemitem{1.}
Conforming code uses only the syntax specified in the standard.
\itemitem{2.}
Conforming code is written in only the sequence specified in the standard.
\itemitem{3.}
Conforming code is written using only the {\word functions}, {\word macros},
{\word special forms}, variables, and constants specified in this standard.
Use of language extensions to the syntax specified
in the standard, or dependence upon the existence of those extensions,
is not allowed in conforming code.
\itemitem{3.}
The definitions of all other {\word functions}, {\word macros}, or
{\datatype symbols}
that are used by the code must accompany
the code.
\itemitem{4.}
Conformance will not be machine-checkable.
\endlist
Portable code is required to produce equivalent results and
observable side effects in all conforming implementations.
It is possible for conforming code to
run in all conforming implementations, but to have allowable
implementation-dependent behavior that could make it non-portable.
∂01-Mar-89 1138 X3J13-mailer Section 1.6
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 11:38:01 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA02703; Wed, 1 Mar 89 11:35:58 PST
Message-Id: <8903011935.AA02703@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA02703; Wed, 1 Mar 89 11:35:58 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:23
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 1.6
%%Implementation-defined Features
The following sections contain lists of implementation-dependent
language characteristics.
For more
information about each of these implementation dependencies, see
Chapters 6 and 7 for the description of the {\word tool} being qualified.
\beginsubSection{Values}
%%\item{2.}
\beginlist
\item{1.}
An implementation determines the initial values of the {\word tools}
in Figure {\chapno--\the\capno}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt boole-clr}&{\tt boole-set}\cr
{\tt boole-1 }& {\tt boole-2}\cr
{\tt boole-c1}&{\tt boole-c2}\cr
{\tt boole-and}&{\tt boole-xor }\cr
{\tt boole-eqv}&{\tt boole-nand}\cr
{\tt boole-nor }&{\tt boole-orc1}\cr
{\tt boole-orc2}& \cr
& \cr
{\tt array-dimension-limit }&{\tt array-rank-limit }\cr
{\tt array-total-size-limit }&{\tt call-arguments-limit }\cr
{\tt multiple-values-limit}&{\tt lambda-parameters-limit }\cr
{\tt char-bits-limit }&{\tt char-code-limit }\cr
& \cr
@var[features] & {\tt internal-time-units-per-second} \cr
& \cr
{\tt most-positive-fixnum }&{\tt most-negative-fixnum } \cr
{\tt most-positive-short-float }&{\tt least-positive-short-float }\cr
{\tt most-positive-double-float }&{\tt least-positive-double-float }\cr
{\tt most-positive-long-float }&{\tt least-positive-long-float }\cr
{\tt most-positive-single-float }&{\tt least-positive-single-float }\cr
{\tt most-negative-short-float }&{\tt least-negative-short-float }\cr
{\tt most-negative-single-float }&{\tt least-negative-single-float }\cr
{\tt most-negative-double-float }&{\tt least-negative-double-float }\cr
{\tt most-negative-long-float }&{\tt least-negative-long-float }\cr
{\tt short-float-negative-epsilon }&{\tt single-float-negative-epsilon }\cr
{\tt double-float-negative-epsilon }&{\tt long-float-negative-epsilon }\cr
& \cr
@var[load-verbose] & @var[print-array] \cr
@var[print-pretty] &@var[random-state] \cr
@var[read-default-float-format] & \cr
\noalign{\vskip -9pt}
}}
\caption{Implementation-defined values}
\endfig
%%\item{42.}
\item{2.} The implementation determines the defaults for the
@Kwd[rehash-size] and
@Kwd[rehash-threshold]
arguments for
{\function make-hash-table}.
%%\item{44.}
\item{3.} The implementation determines the way in which a
{\datatype sequence} is initialized if an @Kwd[initial-element]
argument is not supplied. See {\function make-sequence}.
The implementation determines the way in which a
{\datatype string} is initialized if an @Kwd[initial-element]
argument is not supplied. See {\function make-string}.
Also, the implementation determines the way in which an
{\datatype array\/} is initialized if @Kwd[initial-element]\rm,
@Kwd[initial-contents]\rm, or @kwd[displaced-to]
arguments are not supplied. See {\function make-array\/}.
%%\item{58.}
\item{4.} Valid values for the argument to
{\function char-bit} and {\function set-char-bit}
are implementation-dependent.
\endlist
\endsubSection%{Values}
\beginsubSection{Results}
\beginlist
\item{1.}
%%12.5.2 7
An implementation may return the result of the
absolute value of a {\datatype complex}
number composed of {\datatype integer}
real and imaginary parts as either a {\datatype floating}-point
number or an {\datatype integer}. See {\function abs}.
%%\item{7.}
\item{2.}
An implementation determines the result returned from
{\function lisp-implementation-type},
{\function type-of},
{\function
lisp-implementation-version}, and {\function software-version}.
%%\item{18.}
\item{3.} An implementation determines the result of {\function digit-char}
when more than one character object can encode the supplied weight in
the given radix.
%%\item{20.}
\item{4.} An implementation may determine the consequences in
{\function do} and
{\function do{\tt $*$}} when the index variable is changed within the iteration
loop.
%%\item{30.}
\item{5.} The result of {\function
file-position} for a character file is implementation-dependent.
%%\item{34.}
\item{6.} An implementation determines the order of elements in the results
of {\function intersection},
{\function set-difference}, and {\function
union} and derivatives of those functions.
Some element-processing aspects of sorting are implementation-dependent.
See {\function sort}.
%%\item{36.}
\item{7.} Whether or not {\function length}
or any sequence operation returns when given a circular
{\datatype list} is implementation-dependent.
%%\item{39.}
\item{8.} The implementation determines the {\word type} of
the result of {\function log} ({\datatype integer} or {\datatype
floating-point})
when its arguments are both {\datatype integers} and the result is a whole
number.
%%\item{41.}
\item{9.} The implementation determines the result of {\function make-char}.
%%\item{46.}
\item{10.} An implementation determines the result of
{\tt (eq (symbol-name (make-symbol x)) x)}.
%%\item{47.}
\item{11.}
An implementation determines the {\word type}
of the result of {\function
max} and {\function min} in the following cases.
\beginlist
\itemitem{a.}
If the arguments are a mixture of {\datatype rationals} and
{\datatype floating-point}
numbers and the largest argument
is a {\datatype rational}.
\itemitem{b.} If the largest argument is a {\datatype floating-point}
number of a smaller format
than the largest format of any {\datatype floating}-point argument.
\endlist
In addition, if one or more of the arguments are equal, then any one
of them may be chosen as the value to return.
%%\item{62.}
%\item{12.} {\function special-form-p} can return a non-@nil\ value,
%the identity of which is implementation-dependent.
%%\item{63.}
\item{12.} If the argument to {\function sqrt} is an {\datatype integer},
the result may be either an {\datatype integer}
or a {\datatype float}ing-point number depending on the
implementation. Also, if the argument to {\function sqrt} is a negative
{\datatype integer},
the result
may be either a
{\datatype complex} number with {\datatype integer} components or
a {\datatype complex} number with {\datatype floating}-point components.
%%\item{64.}
\item{13.} If no characters in the argument to {\function string-trim},
{\function string-left-trim}, {\function string-right-trim},
{\function string-upcase}, {\function string-downcase}, and
{\function string-capitalize} need to be changed, then the implementation can
either return the argument itself or a copy of it.
This is true for all destructive
{\datatype sequence} functions.
%%\item{71.}
\item{14.} When the arguments to
a mathematical {\word function} are
all {\datatype rational} and the true mathematical result
is also (mathematically) rational, then unless otherwise noted
an implementation is free to return either an accurate result of
{\word type} {\datatype rational}
or a {\datatype single-float} approximation.
If the arguments are all {\datatype rational}
but the result cannot be expressed
as a {\datatype rational} number, then a {\datatype single-float}
approximation is always returned.
\endlist
\endsubSection%{Results}
\beginsubSection{Data Representation and Typing}
\beginlist
%%\item{5.}
\item{1.}
An implementation determines the representation of a byte specifier.
%%\item{9.}
\item{2.}
An implementation determines the {\word type} of the {\word object} returned
from {\function coerce} when the result is specified to be a specialized
type.
%%\item{11.}
\item{3.}
An implementation can define declaration specifiers other than the ones
given in the description of {\function declare}.
%%\item{27.}
\item{4.} An implementation determines the format of the environment
argument to {\function evalhook} and
the argument that comes to {\function defmacro} via \&environment; the
{\function defmacro} and
{\function evalhook} environment arguments are not necessarily in the same
format.
%%\item{75.}
\item{5.} The existence of
{\word types} that are not {\word subtypes} of {\datatype common}
is implementation-dependent.
\endlist
\endsubSection%{Data Representation and Typing}
\beginsubSection{Program and Control Structure}
\beginlist
%%\item{13.}
%\item{1.}
%An implementation
%may or may not check for any dynamic {\word bindings}
%of the first argument to {\function defconstant} at the time
%{\function defconstant} is executed.
%%\item{14.}
\item{1.}
An implementation determines the way that {\function defmacro}
actually installs a macro function.
%%\item{15.}
\item{2.}
An implementation determines the code generated by {\function defsetf}.
%%\item{16.}
\item{3.}
The following are implementation-dependent features of {\function defstruct}:
\beginlist
\itemitem{a.} The initial contents of a slot, when they have not been provided,
are specified by the implementation.
\itemitem{b.} The access functions may be declared {\function inline}.
\itemitem{c.} The incorrect use of access functions may or may not be checked
by an implementation.
\itemitem{d.} For included slots, an implementation may or may not check
{\word type} assignments.
\itemitem{e.} If the {\keyword :type} option is not supplied, the implementation
determines the representation of the {\datatype structure}.
%%(see clean-up issue)
\endlist
%%\item{35.}
\item{4.} The permissibility of non-standard {\word lambda-list}
keywords is implementation-dependent.
%%\item{40.}
\item{5.}
An implementation is free
to implement as a {\word special form} any {\word construct}
described in this standard as a {\word macro},
if an equivalent {\word macro} definition is also provided.
See {\function macro-function}.
%%\item{60.}
\item{6.}
The exact expansion for any particular form given to {\function setf}
may be implementation-dependent.
%%\item{76.}
\item{7.} The internal representation of
a backquoted {\word form} is implementation-dependent.
\endlist
\endsubSection%{Program and Control Structure}
\beginsubSection{Comparisons}
\beginlist
%%\item{6.}
\item{1.}
An implementation determines the way font information is compared in the
functions {\function char-equal, char-not-equal, char-lessp, char-greaterp,
char-not-greaterp}, and {\function char-not-lessp}. Where not
specified by this standard, the ordering of
characters is implementation-dependent.
\endlist
\endsubSection%{Comparisons}
\beginsubSection{Numerical Calculations}
\beginlist
%%\item{8.}
\item{1.} {\function minusp},
{\function eql},
{\function float-sign}, and
{\function zerop}
are affected by the presence
of {\tt $-0.0$} in an implementation.
%%\item{24.}
\item{2.} Whether or not two {\datatype numbers} or {\datatype characters}
are {\function eq}
depends on the implementation.
%%\item{26.}
\item{3.} Whether two {\datatype floating}-point
numbers of different {\word types} are {\function eql} depends
on the implementation because it is possible for an implementation to
have less than four floating-point data types.
%%%\item{29.}
%\item{4.} An implementation may use different algorithms
%for the cases of a {\datatype rational} second
%argument and a {\datatype floating}-point
%second argument to {\function expt}.
%%\item{55.}
\item{4.} Random number generation is implementation-dependent.
%%\item{70.}
\item{5.} For the {\word operators} in Figure {\chapno--\the\capno},
an implementation may process the arguments in any manner consistent
with associative (and possibly commutative) rearrangement.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0
plus 1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt + }&{\tt * }&{\tt max }\cr
{\tt min }&{\tt =}&{\tt /=}\cr
{\tt < }&{\tt >}&{\tt <=}\cr
{\tt >= }&{\tt gcd}&{\tt lcm}\cr
{\tt logior}&{\tt logxor}&{\tt logand}\cr
{\tt logeqv}&{\tt lognand}&{\tt lognor}\cr
{\tt logandc1}&{\tt logandc2}&{\tt logorc1}\cr
{\tt logorc2}&{\tt boole}&\cr
\noalign{\vskip -9pt}
}}
\caption{Mathematically associative operators}
\endfig
Implementations may differ in
which automatic coercions are applied because of differing
orders of argument processing.
%%\item{72.}
\item{6.}
The precise definitions of {\datatype short-float},
{\datatype long-float}, {\datatype single-float}, and
{\datatype double-float} are implementation-dependent.
\endlist
\endsubSection%{Numerical Calculations}
\beginsubSection{User Interface}
\beginlist
%%\item{.}
\item{1.}
An implementation determines the user interface for the read-eval-print loop
in the {\word
operators} and variables in Figure {\chapno--\the\capno}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0
plus 1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt break }&{\tt check-type }&{\tt describe }\cr
{\tt disassemble }&{\tt inspect }&{\tt step }\cr
{\tt warn }&{\tt y-or-n-p }&{\tt yes-or-no-p }\cr
{\tt error }&{\tt cerror }&{\tt ccase }\cr
{\tt ccase }&{\tt ctypecase }&{\tt Anything that uses cerror }\cr
\noalign{\vskip -9pt}
}}
\caption{User interface operators and variables}
\endfig
\endlist
\endsubSection%{User Interface}
\beginsubSection{Input/Output}
\beginlist
%%\item{17.}
\item{1.} An implementation determines whether an attempt by {\function
delete-file} to delete a non-existent file is considered to be successful.
%%\item{19.}
\item{2.} An implementation may define keywords to be used with
{\function directory}.
%%\item{31.}
\item{3.} An implementation determines the precise actions of
{\function finish-output}, {\function clear-output}, and {\function
force-output}.
%%\item{31a.}
\item{4.} {\datatype Streams}
may be implemented in an asynchronous or buffered manner.
%%\item{32.}
\item{5.} {\function format} has the following implementation-defined
features:
\beginlist
%% CLean-up item on this
\itemitem{a.} {\tt @tilde C} prints a character in an implementation-dependent
abbreviated format.
\itemitem{b.} The precise output for {\tt @tilde :{\char '100}C} depends
on the implementation.
\itemitem{c.} When rounding up and rounding down would produce printed values
equidistant from the scaled value of the argument, then the implementation
is free to use either one.
\itemitem{d.} For the {\tt @tilde \$} operation, if the magnitude of the argument is so large or small
that more than 100 digits would have to
be printed, then an implementation is free, at its discretion, to print
the number using exponential notation.
\itemitem{e.} For the {\tt @tilde \$} operation, if
the argument is a {\datatype rational} number,
then it is coerced to be a {\datatype single-float}
or processed by any other method that has essentially the
same behavior.
Only a finite number of digits may be printed.
\endlist
%%\item{37.}
\item{6.} The means by which a text (character file)
is distinguished from an object (binary) file is
implementation-dependent.
%%\item{38.}
\item{7.} The selection by {\function load} of a file type when there
is a choice is implementation-dependent.
%%\item{43.}
\item{8.} The implementation determines the internal representation
of a {\datatype pathname}. See {\function make-pathname}.
%%\item{48.}
\item{9.} The following aspects of {\function open}
are implementation-dependent:
\beginlist
\itemitem{a.} {\keyword :supersede}
\itemitem{b.} An implementation is required to recognize all of
the following {\keyword if-exists} keywords
and to do something reasonable in the context of the host operating
system:
{\keyword :error},
{\keyword :new-version},
{\keyword :rename},
{\keyword :rename-and-delete},
{\keyword :overwrite},
{\keyword :append},
{\keyword :supersede}, or
@false\rm.
\itemitem{c.} If it is impossible for an implementation to handle some option
in a manner close to what is specified in this manual, an error may be
signalled.
\endlist
%%\item{50.}
\item{10.} {\function parse-namestring}
may or may not signal an error if
the representation of a {\datatype pathname}
is surrounded on either side by
whitespace characters, depending on the implementation.
Whether or not {\function parse-namestring} supplies
the
standard default device as the device component
of the resulting {\datatype pathname} depends on the implementation.
%%\item{51.}
\item{11.} The {\datatype pathname} namestring
syntax is implementation-dependent.
The printed representation of a pathname
typically designates {\keyword :wild} by an asterisk; however, this is
implementation-dependent.
%%\item{52.}
\item{12.} A {\datatype character} name or a {\datatype pathname}
that is typed out
is acceptable as input in only the implementation which typed it.
Which names for characters are chosen to print is
implementation-dependent, although standard names are
chosen over non-standard names. See {\function write}.
%%\item{53.}
\item{13.} The printed representation of a
{\datatype random-state} object is implementation-dependent.
%%\item{54.}
\item{14.} {\word Objects} which do not have a specific syntax
specified in this manual are printed in an implementation-dependent manner.
%%\item{68.}
\item{15.} The {\arg host}
argument to {\function user-homedir-pathname}
defaults in an implementation-dependent manner.
%%\item{77.}
\item{16.} Whether the following
character names are supported is implementation-dependent:
@f[rubout]\rm, @f[page]\rm,
@f[tab]\rm,
@f[backspace]\rm,
@f[return]\rm, and
@f[linefeed]\rm.
%%\item{78.}
\item{17.} Whether
characters with non-zero {\arg bits} and {\arg font} attributes
syntax
descriptions are in the {\datatype readtable} is implementation-dependent.
\endlist
\endsubSection%{Input/Output}
\beginsubSection{Compiling}
\beginlist
%%\item{10.}
\item{1.}
An implementation determines the following for {\function compile-file}:
\beginlist
\itemitem{a.} The contents of the file created by {\function compile-file}.
\itemitem{b.} The file
specification (if one is not supplied)
for the file created by {\function compile-file}.
\endlist
%%\item{12.}
\item{2.}
An implementation's compiler can ignore declaration
specifiers except for {\tt declaration}, {\tt special}, and
{\tt notinline}.
%%\item{25.}
\item{3.} An implementation may ``collapse'' constants or portions of constants
in code to be compiled if they appear to be {\function eq}
or {\function eql} and are {\function equal}.
See ``Compilation''.
%%\item{79.}
\item{4.} The representation of the {\word object} produced by
the compiler, and the internals of the compiler
are implementation-dependent, except that {\function compile} produces
a {\datatype compiled-function}.
\endlist
\endsubSection%{Compiling}
\beginsubSection{Miscellaneous}
\beginlist
%%\item{4.}
\item{1.}
An implementation determines the specifics of the
debugger that {\function break} enters.
%%\item{74.}
\item{2.} Although functions that manipulate {\datatype packages}
generally signal
name conflict errors before making any change to the package structure, an
implementation may {\function export}
each of a given list of {\datatype symbols} separately.
%%\item{49.}
\item{3.} The contents of the @f[system] package are determined by
the implementation.
%%\item{57.}
\item{4.} The frequency of execution of test and key
functions for all sequence functions is implementation-dependent.
The implementation of
{\function search} may choose to search the {\datatype sequence} in any order.
%%\item{65.}
\item{5.} The manner in which a
hash code is computed by {\function sxhash}
is implementation-dependent.
%% clean-up pending for this
%%\item{69.}
\item{6.} The optional argument {\arg extension}
for {\function
vector-push-extend}
defaults to a ``reasonable'' implementation-dependent
value.
%%\item{73.}
\item{7.} A {\datatype symbol's} property list may have defined components.
\endlist
\endsubSection%{Miscellaneous}
\beginsubSection{Programming Environment}
\beginlist
%%\item{22.}
\item{1.} An implementation may or may not provide a resident editor.
See {\function ed}.
%%\item{23.}
\item{2.} An implementation determines the means by which
function text is obtained when {\tt (ed {\it symbol})} is invoked.
%%\item{33.}
\item{3.} An implementation determines the units used in representing
Internal Time.
See {\function get-internal-run-time}.
%%\item{56.}
\item{4.} The information {\function room} prints is
implementation-dependent.
%%\item{66.}
\item{5.} The nature and
format of the information printed by {\function time}
is implementation-dependent.
%%\item{67.}
\item{6.} The following are implementation dependencies of
tracing.
\beginlist
\itemitem{a.} {\function trace} and {\function untrace} may accept
implementation-dependent argument formats.
\itemitem{b.} The format of the {\function trace}
output is implementation-dependent.
\endlist
\endlist
\endsubSection%{Programming Environment}
∂01-Mar-89 1159 X3J13-mailer New versions of standard files available
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 11:59:21 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA05099; Wed, 1 Mar 89 11:57:05 PST
Message-Id: <8903011957.AA05099@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA05099; Wed, 1 Mar 89 11:57:05 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:02
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: New versions of standard files available
New versions of the standard files that will be voted on in March are available
on hudson.dec.com. There will probably still be changes to section 5.1 (Errors),
so plan to copy and review that last. All these files are contained in
march-27-ballot.dvi, if you can use that file type. If you want to build this
yourself, use march-27-ballot.tex as well as the other files necessary for
any build (kcamfont.tex, kcmacros.tex, macros2.tex, march-27-ballot.tc).
S1100.SCOPE-PURPOSE-AND-HISTORY
S1200.ORGANIZATION-OF-THE-DOCUMENT
S1300.REFERENCED-PUBLICATIONS
S1400.DEFINITIONS
S1500.COMPLIANCE
S1600.IMPLEMENTATION-DEFINED-FEATURES
S1700.LANGUAGE-EXTENSIONS
S2100.INTRODUCTION
S2200.TYPES
S5100.ERRORS
S5200.INPUT-OUTPUT
S5300.INTERFACE-WITH-PROGRAMMING-ENVIRONMENT
S5400.GENERALIZED-REFERENCE
Please let me know if you have trouble accessing these files.
I will be mailing the sources to you for review.
kathy chapman
∂01-Mar-89 1203 X3J13-mailer Section 1.3
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 12:03:44 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA05782; Wed, 1 Mar 89 12:01:39 PST
Message-Id: <8903012001.AA05782@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA05782; Wed, 1 Mar 89 12:01:39 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:22
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 1.3
%%Referenced Publications
\beginlist
\item{} {\it The Anatomy of Lisp}, John Allen, McGraw-Hill, 1978.
\item{} {\it Compile-time Evaluation and Code Generation for Semantics-directed
Compilers}, Andrew W. Appel, Carnegie-Mellon University, 1985.
\item{} {\it The Definition of Programming Languages}, Andrew D. McGettrick,
Cambridge University Press, 1980.
\item{} {\it Desiderata for the Standardisation of Lisp}, Julian Padget et.
al., 1986 ACM Conference on Lisp and Functional Programming, 1986.
\item{} {\it Formal Specification of Programming Languages - A Panoramic
Primer}, Frank G. Pagan, Prentice-Hall, Inc, 1981.
\item{} {\it $Revised↑3$ Report on the Algorithmic Language Scheme},
Jonathan Rees and William Clinger (editors), SIGPLAN Notices V21, \#12,
December, 1986.
%\item{} {\it Denotational Semantics}, David A. Schmidt, Allyn and Bacon,
%1986.
\item{} {\it Common LISP the Language}, Guy L. Steele, Jr., Digital Press,
1984.
%\item{} {\it Denotational Semantics: The Scott-Strachey Approach to Programming
%Language Theory}, Joseph E. Stoy, MIT, 1977.
\item{} {\it A Programmer's Guide to Common Lisp}, Deborah G. Tatar,
Digital Press, 1987.
\item{} {\it History of
Programming Languages}, edited by Richard Wexelblat, Academic Press,
1981.
\item{} {\it NIL -- A Perspective}, JonL White, MacSyma User's Conference,
1979.
\item{} {\it Common LISPcraft}, Robert Wilensky, W. W. Norton, 1986.
\endlist
∂01-Mar-89 1207 X3J13-mailer Section 2.1
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 12:06:27 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA06314; Wed, 1 Mar 89 12:04:26 PST
Message-Id: <8903012004.AA06314@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA06314; Wed, 1 Mar 89 12:04:26 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:24
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 2.1
%% Introduction to Objects and Types
%% 2.0.0 4
%% 6.2.1 1
A {\word data type} (a {\word type})
is a (possibly infinite) set of
{\word objects}. An {\word object} can belong to more than one
{\word type}. @Funref[typep] is used to determine
whether an {\word object} is of a given {\word type},
a set membership test, while {\function subtypep}
is a subset test.
@Funref[type-of] returns a {\word type}
to which an {\word object} belongs.
%% 9.1.0 1
Type declarations can be embedded in executable
code using {\function declare}.
Global type declarations are established by {\function proclaim}.
%% 9.3.0 1
%The special form {\function the} is used to declare
%the {\word type} of the value of an
%unnamed {\word form}.
%The form {\tt (the type form)} means
%that the value of {\tt form}
%is declared to be of type {\tt type}.
%% 1.1.0 4
%% 9.0.0 3
%All type declarations are optional
%and correct type declarations do not affect the meaning
%of a correct program.
%All type declarations are of an advisory nature, and may be used
%by the @xlisp\ system in performing error checking
%or producing more efficient compiled code.
%% 9.0.0 4
The consequences are undefined if a program violates a
type declaration (such as a {\function type} declaration),
but an implementation is
not required to detect such errors.
%% 9.2.0 1
%% 2.0.0 1
Data {\word objects}, not variables, are {\word typed}.
Normally, any variable
can have any @xlisp\ {\word object} as its value.
It is possible to make an explicit
type declaration that a variable will
take on one of only a limited set of values.
%% 2.0.0 5
@clisp\ {\word types} are arranged in a directed acyclic graph.
%Therefore,
%it is possible for an {\word object} to belong to more than one
%{\word type}.
%% 2.12.0 1
%%% 19.1.0 1
%{\word Structures} created by @Macref[defstruct]
%are instances of user-defined {\word types}.
%%% Beginning of CLOS stuff
%\beginSection{Introduction}
%
The \CLOS\ is based on
{\word generic functions}, multiple inheritance, declarative {\word method}
combination, and a meta-object protocol.
%
%The first two chapters of this specification present a description of
%the standard Programmer Interface for the \CLOS. The first chapter
%contains a description of the concepts of the \CLOS, and the second
%contains a description of the functions and macros in the \CLOS\
%Programmer Interface. The chapter ``The \CLOS\ Meta-Object
%Protocol'' describes how the \CLOS\ can be customized.
%
The fundamental {\word objects} of the \CLOS\
are {\word classes}, {\word instances},
{\word generic functions}, and {\word methods}.
A {\bit class\/} object determines the structure and behavior of a set
of other {\word objects}, which are called its {\bit instances}.
Every {\word object} is an {\bit
instance\/} of a {\word class}. The
{\word class} of an {\word object} determines the set of
operations that can be performed on the {\word object}.
See ``Generic Functions and Methods''.
%%\endSection%{Introduction}
∂01-Mar-89 1232 X3J13-mailer Section 1.1
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 12:32:28 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA09717; Wed, 1 Mar 89 12:30:00 PST
Message-Id: <8903012030.AA09717@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA09717; Wed, 1 Mar 89 12:30:00 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:21
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 1.1
%%Scope, Purpose, and History
\beginsubSection{Scope and Purpose}
The standard specification set forth in this document
is designed to promote the portability of @clisp\ programs
among a variety of data-processing systems. It is intended for use
by implementors and knowledgeable programmers, and is not a tutorial.
This standard is intended to be a language specification
rather than an implementation specification.
An
implementation is free to achieve the semantics
specified in this standard by any means. The @clisp\ definitions
in Chapters 6 and 7 need not be reflected directly in the implementation.
\endsubSection%{Scope and Purpose}
\beginsubSection{History}
Lisp is the second oldest high-level programming language still in current use.
(The oldest high-level programming language still in widespread use
is Fortran.)
@clisp\ is a joint-venture language stemming from several
research and development projects in the late 1970's. Its
roots reveal why some of the features of the language were
added. From a short look at these roots, it can also be seen
how these features influence the architectural requirements
for a high-quality implementation.
From the mid-1960's through much of the 1970's, DEC's PDP10 computer
was the mainstay of Lisp work at MIT and Stanford's AI and Computer
Science Labs, at BBN in Cambridge, at CMU, and at selected other sites.
Designed in the early
1960's, the PDP10 had the unique advantage of being influenced by
John McCarthy, the ``Grandfather of Lisp'', and as a result has
half-word instructions suitable for {\word car} and {\word cdr}
instructions, and
stack instructions to facilitate recursive programming.
But the limitations of this old machine were painfully
evident by 1973, two of which were
the high cost to support a single researcher,
and the small address space available ($2↑{18}$ = 262,144 words).
To alleviate the latter problem, BBN Lisp (developed at Bolt, Bernak,
\& Newman in Cambridge, and later, with Xerox's
participation, called Interlisp)
added a ``black hole'' feature somewhat akin to ``paging''
on a function basis rather than on a page-boundary basis. MacLisp
(developed at the MIT AI Lab and Laboratory for Computer Science)
added an ``autoload'' feature, whereby only the functions actually used
would be loaded in to ``core''. Large applications such as the
symbolic algebra system MACSYMA and the Interlisp programing development
environment were driving forces for larger address space capabilities.
In the early 1970's, at Xerox's Palo Alto Research Center, L. Peter Deutch
conceived of a personal workstation with an architecture
tailored to the needs of Lisp. This architecture would allow
a machine to be affordable to an
individual researcher and to have sufficient power to run large Lisp
applications.
Soon thereafter, Richard Greenblatt began work
on a similar design at MIT's AI Laboratory.
Eventually, a dialect of Interlisp known as Interlisp-D became available
on
the ``D-series'' machines manufactured by Xerox, and an upward-compatible
extension of MacLisp became available on the early MIT ``Lisp'' machines.
Both of these efforts culminated in commercial Lisp machines that were
seen in laboratory prototype at about the time of the 1980 Lisp Conference
at Stanford, and were marketable by 1981.
In another direction, in the late 1970's the MacSyma group at MIT
began
a project called New Implementation of Lisp (NIL). In additon
to capitalizing on the large address space and other hardware
capabilities of the VAX, one of the stated goals of NIL was to fix many
of the historic, but annoying, little problems of the Lisp
language while still retaining an essentially upward-compatible
outlook. At about the same time, a research group
at Stanford University and Lawrence Livermore National Laboratory
began the design of a Lisp to run on the supercomputer,
S-1. Recognizing the similarity of
their goals to those of the MIT NIL project, the S-1 group
began to collaborate with the NIL group.
In a third direction, around 1980, Scott Fahlman and others at CMU
began work on a Lisp to run on the SPICE workstation.
The SPICE machine had a much weaker microcode capability
than the MIT Lisp Machine, so the goal was to emulate as much of the
MIT design as was feasible.
After a DARPA-sponsored meeting on the future of Lisp in April 1981,
representatives
of several of the post-MacLisp efforts (Gabriel, Steele, White, and Fahlman)
decided to join forces by
directing their efforts towards a common, portable dialect of Lisp.
Further design sessions were held at CMU in June 1981. Later that
fall, Symbolics Corporation representatives began assisting in
designing the new dialect.
After the name was chosen (@clisp) the task then turned to a
choice of how much of the design could be retained from the Lisp
machines, and how much seemed to pre-suppose special purpose hardware. Also
there was a task of sorting out which features of conventional
languages for conventional hardware architectures, like compile-time
typing, could be integrated into the new language without damaging
its essential Lisp character. The theorists of each
camp allowed some deviations from what they considered theoretically
best, and the result
was a language suitable for general purpose hardware, but with certain
particular implementational problems to be met.
@maclisp, @lmlisp, @scheme, @interlisp, @slisp, @s1lisp, @newlisp,
@stdlisp, and @psl\
were each considered during the design of
@clisp\rm, and the most useful features of each were incorporated.
{\it Common LISP the Language},
was written by members of the informal design group.
The semantics in {\it Common LISP the Language} were intentionally
underspecified in
places where it was felt that a tight specification would
unduly constrain @clisp\ research and use.
However, industrial use of @clisp\
mandates implementations to produce the same results given the same arguments
in order that code can be ported between implementations.
In addition, @clisp\ users recognized the need to agree on standard
object-oriented and condition systems, iteration facilities, and
a way to handle large character sets.
Therefore, a new language specification, this document, was created by
the X3J13 committee.
\endsubSection%{History}
∂01-Mar-89 1232 X3J13-mailer Section 1.2
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 12:32:32 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA09839; Wed, 1 Mar 89 12:30:26 PST
Message-Id: <8903012030.AA09839@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA09839; Wed, 1 Mar 89 12:30:26 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:21
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 1.2
%%Organization of the Document
This document is divided into seven chapters:
\beginlist
\item{\bull} This introduction.
\item{\bull} A description of @clisp\ types and objects.
\item{\bull} A description of the syntax of @clisp\ objects.
\item{\bull} The @clisp\ evaluation and compilation processes.
\item{\bull} A description of the @clisp\ interfaces to
its environment and a description of the condition
system.
\item{\bull} A catalog of @clisp\ symbols (divided into two chapters).
\endlist
∂01-Mar-89 1234 X3J13-mailer Section 1.4
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 12:34:33 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA09935; Wed, 1 Mar 89 12:32:23 PST
Message-Id: <8903012032.AA09935@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA09935; Wed, 1 Mar 89 12:32:23 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:22
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 1.4
%%Definitions
This section contains notational conventions used in this manual.
The font key to be used in Chapters 1-5
is as follows:
\beginlist
\itemitem{\datatype data-type}
Denotes
@clisp\ {\word data types}.
\itemitem{\word defined word}
Denotes the words whose
definitions appear in the ``Glossary''.
\itemitem{\function tools}
Denotes {\word tools}.
\itemitem{\keyword keywords}
Denotes {\word keywords}.
\endlist
%% 1.2.1 1
All numbers in this book are in decimal notation
unless otherwise noted.
%% 1.2.5 9
The dot appearing in the expression
@f[(sample-macro @i[var] {\char '056} @i[body])]
means that @f[body] stands
for a list of {\word forms},
not just a single {\word form}, at the end of a list.
The following notations are used in this document:
\beginlist
\itemitem{\word @EV\rm}
Indicates {\word evaluation}.
For example:
@Lisp
(+ 4 5) @EV 9
@Endlisp
means that the result of {\word evaluating} the code @f[(+ 4 5)] is @f[9]\rm.
%% 1.2.3 3
\itemitem{\word @EQ}
Indicates code
equivalence.
For example:
@Lisp
(gcd x (gcd y z)) @EQ (gcd (gcd x y) z)
@Endlisp
means that the results and observable
{\word side-effects} of {\word evaluating }
the {\word form}
@f[(gcd x (gcd y z))] are always the same as the results
and observable {\word side-effects} of
@f[(gcd (gcd x y) z)] for any
@f[x]\rm, @f[y]\rm, and @f[z]\rm.
%% 1.2.5 4
\itemitem{@t}
The canonical truth value.
Any {\word object} other than @false\ is construed to be Boolean
``not false,'' that is, ``true.'' The {\datatype symbol} @true\ is
used to mean ``true'' when no other value is more appropriate.
When a {\word function} is said to ``return @i[true]\rm'' or to ``be @i[true]\rm''
in some circumstance, this means that it returns some value other
than @false\rm, but not necessarily @true\rm.
\itemitem{@nil}
Represents the empty {\datatype list} and
the ``false'' value for Boolean tests.
The {\datatype symbol} @f[nil] evaluates to
itself, so @f['nil] and @f[nil] denote the same {\word object}
in terms of evaluation.
The former syntax is used to emphasize that the result is
a {\datatype symbol},
while the latter is used to emphasize that the result is
a boolean value. @f['()]
is used to denote the
empty {\datatype list}
in terms of evaluation. It is used in a quoted structure
or a program structure.
For example:
\screen!
(print ()) ;avoided
'(nil nil) ;list of symbols
'(()()) ;list of empty lists
(defun three () 3) ;Emphasize empty parameter list.
(append '() '()) @EV () ;Emphasize use of empty lists
(not @false) @EV @true ;Emphasize use as Boolean "false"
(get '@nil 'color) ;Emphasize use as a symbol
\endscreen!
When a function is said to ``return @i[false]\rm'' or to ``be @i[false]\rm''
in some circumstance, this means that it returns @false\rm.
\endlist
∂01-Mar-89 1240 X3J13-mailer Section 5.3
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 12:40:11 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA10373; Wed, 1 Mar 89 12:38:09 PST
Message-Id: <8903012038.AA10373@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA10373; Wed, 1 Mar 89 12:38:09 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:26
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 5.3
%% Interface with the Programming Environment
\beginSubsection{Top level loop}
%% 20.2.0 1
The {\function read}-{\function eval}-{\function print} loop
is the highest level of control and consists of an endless
loop that reads an expression, evaluates it, and prints the
results. The parts of the
{\function read}-{\function eval}-{\function print} loop are individually
referred to as the reader, the evaluator, and the printer.
%% 20.2.0 2
The precise nature of the {\function read}-{\function eval}-{\function print}
loop
is not rigorously specified; thus the user interface is
implementation-defined.
%% 20.2.0 3
The {\function read}-{\function eval}-{\function print} loop
traps all {\function throws} and recovers from them.
It prints all values resulting from the evaluation of a
{\word form}.
%% 20.2.0 4
The following variables are maintained by the
{\function read}-{\function eval}-{\function print} loop.
{\tt +, ++, +++, *, **, ***, /, //, ///, -}.
See Chapter 6 for the meanings of these variables.
\endSubsection%{Top level loop}
\beginSubsection{Environment inquiry}
%% 25.4.0 1
Environment inquiry {\word tools} provide information about the
system on which a @clisp\ program is being executed.
These {\word tools}
aid in querying the hardware and software configuration, and
in debugging.
Figure {\chapno--\the\capno} lists the
{\word tools} that are applicable to configuration inquiry.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt @var[features] } & {\tt long-site-name } & {\tt room } \cr
{\tt identity } & {\tt machine-instance } & {\tt short-site-name } \cr
{\tt lisp-implementation-type } & {\tt machine-type } & {\tt software-type }
\cr
{\tt lisp-implementation-version} & {\tt machine-version } & {\tt
software-version } \cr
\noalign{\vskip -9pt} }}
\caption{Configuration inquiry tools}
\endfig
Figure {\chapno--\the\capno} lists the
{\word tools} that are applicable to debugging.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt apropos } & {\tt dribble } & {\tt step } \cr
{\tt apropos-list } & {\tt ed } & {\tt trace } \cr
{\tt describe } & {\tt inspect }& {\tt untrace } \cr
{\tt documentation } & & \cr
\noalign{\vskip -9pt} }}
\caption{Debugging tools}
\endfig
\endSubsection%{Environment inquiry}
\beginsubsubsection{Time}
%% 25.4.1 1
Time is represented in three different ways in @clisp\rm:
Decoded Time, Universal Time, and Internal Time.
The first two representations
are used primarily to represent calendar time, and are
precise only to one second.
Internal Time is used primarily to represent measurements of computer
time (such as run time) and is precise to some implementation-dependent
fraction of a second, as specified by @Conref[internal-time-units-per-second]\rm.
Decoded Time format is used only for absolute time indications.
Universal Time and Internal Time formats are used for both absolute
and relative times.
\beginlist
\itemitem{\bf Decoded time}
%% 25.4.1 2
Decoded Time format represents calendar time as a number of components:
%% 25.4.1 3
\beginlist
\itemitem{\bf Second}
An {\datatype integer} between 0 and 59, inclusive.
%% 25.4.1 4
\itemitem{\bf Minute}
An {\datatype integer} between 0 and 59, inclusive.
%% 25.4.1 5
\itemitem{\bf Hour}
An {\datatype integer} between 0 and 23, inclusive.
%% 25.4.1 6
\itemitem{\bf Date}
An {\datatype integer} between 1 and 31, inclusive (the upper limit actually
depends on the month and year, of course).
%% 25.4.1 7
\itemitem{\bf Month}
An {\datatype integer} between 1 and 12, inclusive; 1 means January,
12 means December.
%% 25.4.1 8
\itemitem{\bf Year}
An {\datatype integer} indicating the year A.D. However, if this
{\datatype integer}
is between 0 and 99, the ``obvious'' year is used; more precisely,
that year is assumed that is equal to the
{\datatype integer} modulo 100 and
within fifty years of the current year (inclusive backwards
and exclusive forwards).
Thus, in the year 1978, year 28 is 1928
but year 27 is 2027. (Functions that return time in this format always return
a full year number.)
%% 25.4.1 10
\itemitem{\bf Day-of-week}
An {\datatype integer} between 0 and 6, inclusive;
0 means Monday, 1 means Tuesday, and so on; 6 means Sunday.
%% 25.4.1 11
\itemitem{\bf Daylight-saving-time-p}
A flag that, if not @false\rm, indicates that
daylight saving time is in effect.
%% 25.4.1 12
\itemitem{\bf Time-zone}
%% should be a clean-up item about this
An {\datatype integer} specified as the number of hours west of GMT
(Greenwich Mean Time). For example, in Massachusetts the time zone is 5,
and in California it is 8. Any adjustment for daylight saving time is
separate from this.
\endlist
\itemitem{\bf Universal time}
%% 25.4.1 13
Universal Time represents time as a single non-negative {\datatype integer}.
For relative time
purposes, this is a number of seconds. For absolute time, this is the
number of seconds since midnight, January 1, 1900 GMT. Thus the time 1
is 00:00:01 (that is, 12:00:01 a.m.) on January 1, 1900 GMT.
Similarly, the time 2398291201 corresponds to time 00:00:01 on January 1,
1976 GMT.
Recall that the year 1900 was not a leap year; for the purposes of
@clisp\rm, a year is a leap year if and only if its number is divisible by 4, except
that years divisible by 100 are not leap years, except that years
divisible by 400 are leap years. Therefore the year 2000 will
be a leap year.
(Note that the ``leap seconds'' that
are sporadically inserted by the world's official timekeepers as an additional
correction are ignored; @clisp\ assumes that every day is exactly 86400
seconds long.)
Because the @clisp\ Universal Time representation uses only
non-negative integers, times before the base time of midnight,
January 1, 1900 GMT cannot be processed by @clisp\rm.
\itemitem{\bf Internal time}
%% 25.4.1 14
Internal Time also represents time as a single {\datatype integer},
in terms of an implementation-dependent unit.
Relative time is measured as a number of these units.
Absolute time is relative to an arbitrary time base.
\endlist
Figure {\chapno--\the\capno} lists the
{\word tools} that are applicable to time.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt time }&{\tt get-decoded-time }\cr
{\tt get-universal-time }& {\tt decode-universal-time }\cr
{\tt encode-universal-time } & {\tt internal-time-units-per-second } \cr
{\tt get-internal-run-time }&{\tt get-internal-real-time }\cr
{\tt sleep } & \cr
\noalign{\vskip -9pt} }}
\caption{Time tools}
\endfig
\endsubsubsection%{Time}
∂01-Mar-89 1243 X3J13-mailer Section 5.4
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 12:43:35 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA10362; Wed, 1 Mar 89 12:41:24 PST
Message-Id: <8903012041.AA10362@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA10362; Wed, 1 Mar 89 12:41:24 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 Mar 89 07:27
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 5.4
%% Generalized Reference
When it is stated that an argument to a {\word function} or
{\word macro} must be
a generalized reference, this means that the argument must follow the
rules specified in this section. The definition for generalized reference
is given in terms of {\function setf},
which performs access and update operations within the
same {\word form}.
Figure {\chapno--\the\capno} contains examples of the use of {\function setf}.
Note that the values returned by evaluating the {\word forms} in column two
are not necessarily the same as those obtained by evaluating the {\word
forms}
in column three.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus
1fil&#\hfil\tabskip \dimen0 plus 1fil&#\hfil\cr
\noalign{\vskip -9pt}
\hfil\bf Access function & Update function & Update using {\function setf} \cr
\noalign{\vskip 2pt\hrule\vskip 2pt}
{\tt x }&{\tt (setq x datum) }&{\tt (setf x datum) }\cr
{\tt (car x) }&{\tt (rplaca x datum) }&{\tt (setf (car x) datum) }\cr
{\tt (symbol-value x) }&{\tt (set x datum) }&{\tt (setf (symbol-value x) datum) }\cr
\noalign{\vskip -9pt}
}}
\caption{Examples of setf}
\endfig
Figure {\chapno--\the\capno} lists the {\word operators}
that are applicable to generalized reference. Some manipulate generalized
references and some manipulate {\function setf} methods.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus
1fil&#\hfil\tabskip \dimen0 plus 1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt setf }&{\tt psetf }&{\tt shiftf }\cr
{\tt rotatf }&{\tt getf }&{\tt remf }\cr
{\tt incf }&{\tt decf }&{\tt push}\cr
{\tt pop }&{\tt assert }&{\tt ctypecase }\cr
{\tt ccase} &{\tt define-modify-macro }&{\tt defsetf }\cr
{\tt define-setf-method }&{\tt get-setf-method }&{\tt get-setf-method-multiple-value }\cr
\noalign{\vskip -9pt}
}}
\caption{Generalized reference operators}
\endfig
%% 7.2.0 29
%% 7.2.0 30
These {\word operators} must guarantee that
subforms of generalized references are
evaluated
exactly as many times as they appear in the source program, and
they are evaluated
in exactly the same order as they appear in the source
program
\issue{PUSH-EVALUATION-ORDER}
(left to right)
whenever possible. The left-to-right rule does not
remove the obligation on writers of {\word macros} and
users of {\function define-setf-method}
to ensure
left-to-right order, however.
\endissue{PUSH-EVALUATION-ORDER}
\issue{PUSH-EVALUATION-ORDER}
\beginlist
\itemitem{1.}
The evaluation ordering of subforms within a generalized reference
is determined by the order specified by the second value returned by
{\function get-setf-method}.
For all predefined generalized references ({\function getf}, {\function ldb}),
this order of evaluation is exactly left-to-right. When a generalized
reference is derived from a macro expansion, this rule is applied after the
macro is expanded to find the appropriate generalized reference.
If the user writes a {\function defmacro} or
{\function define-setf-method}
that does not preserve order, the order specified in the
user's code holds. For example, given
@lisp
(defmacro wrong-order (x y) `(getf ,y ,x))
@endlisp
then
@lisp
(push value (wrong-order place1 place2))
@endlisp
will evaluate {\tt place2} first and then {\tt place1}
because that is the order they
are evaluated in the macro expansion.
\itemitem{2.}
For the {\word macros}
that manipulate generalized references ({\function push},
{\function pushnew}, {\function getf\/}, {\function remf\/},
{\function incf\/}, {\function decf\/}, {\function shiftf\/}, {\function rotatef\/},
{\function psetf\/}, {\function setf\/}, {\function pop}, and those
defined by {\function define-modify-macro}) the subforms of the
macro call are evaluated exactly once
in left-to-right order, with the subforms of the generalized references
evaluated in the order specified in (1).
{\function push}, {\function pushnew}, {\function getf\/}, {\function remf\/},
{\function incf\/}, {\function decf}, {\function shiftf\/}, {\function rotatef\/},
{\function psetf\/}, {\function pop} evaluate all
subforms before modifying any of the generalized reference locations.
{\function setf\/} (in
the case when {\function setf\/} has more than two arguments)
performs its operation
on each pair in sequence, i.e., in
@lisp
(setf place1 value1 place2 value2 ...)
@endlisp
the subforms of {\tt place1} and {\tt value1} are evaluated, the location
specified by
{\tt place1} is modified to contain the value returned by
{\tt value1}, and
then the rest of the {\function setf\/} form is processed in a like manner.
\itemitem{3.}
For {\function check-type}, {\function ctypecase}, and
{\function ccase}, subforms of the generalized
reference are evaluated once as in (1), but may be evaluated again if the
type check fails in the case of {\function check-type}
or none of the cases hold in
{\function ctypecase} and {\function ccase}.
\itemitem{4.}
For {\function assert}, the order of evaluation of the generalized
references is not specified.
\endlist
Rules 2, 3 and 4 cover all macros defined in @clisp\ that manupulate
generalized references.
@lisp
(let ((ref2 (list '())))
(push (progn (princ "1") 'ref-1)
(car (progn (princ "2") ref2)))) @EV "12"
@endlisp
@lisp
(let (x)
(push (setq x (list 'a))
(car (setq x (list 'b))))
x) @EV (((a) . b))
@endlisp
{\function push} first evalutes {\tt (setq x (list 'a)) @EV\ (a)},
then evaluates {\tt (setq x (list 'b)) @EV\ (b)},
then modifies the {\word car} of this latest value to be {\tt ((a) . b)}.
\endissue{PUSH-EVALUATION-ORDER}
%% 7.2.0 31
For example, in
{\tt (setf {\arg reference} {\arg value})}
{\arg value}
must be evaluated after all the subforms of {\arg reference} because
{\arg value} appears to the right of them.
%% 7.2.0 32
The expansion of these {\word operators} must consist of code that follows these
rules or has the same effect as such code. This is accomplished by
introducing temporary variables bound to the
\issue{PUSH-EVALUATION-ORDER}
subforms of the macro call.
\endissue{PUSH-EVALUATION-ORDER}
As an optimization in the implementation,
temporary variables may be eliminated whenever it
can be proven that removing them has no effect on the semantics of the program.
For example, a constant need never be saved in a temporary variable.
A variable or any {\word form} that does not have side effects need not be
saved in a temporary variable if it can be proven that its value will
not change within the scope of the generalized reference.
%% 7.2.0 57
A {\function setf\/} method may be derived from any
generalized reference.
A {\function setf\/} method
describes how to store into that generalized reference and which subforms of
the macro call are evaluated.
%% 7.2.0 59
Given knowledge of the subforms of the macro call,
it is possible to avoid evaluating
them multiple times or in the wrong
order. A {\function setf\/}
method for a given access form can be expressed as
five values:
%% 7.2.0 60
\beginlist
%% 7.2.0 64
\itemitem{\bf List of temporary variables}
The temporary variables
will be bound to the {\word values} of
the value forms sequentially as if by @Specref[let*]\rm.
\itemitem{\bf List of value forms}
The values of the value forms (these are subforms of the access form)
are bound to the temporary variables.
%% 7.2.0 61
%% 7.2.0 65
\itemitem{\bf List of store variables}
The store variables (these are temporary variables)
are to be bound to the values of the generalized reference form,
that is, the values to be
stored into the variable.
%% 7.2.0 62
\itemitem{\bf Storing form}
The storing form modifies the value of the
generalized reference and guarantees to return the value of the
store variable as
its value; these are the correct values for {\function setf\/} to
return.
The storing form may contain references to the temporary and store variables.
%% 7.2.0 63
\itemitem{\bf Accessing form}
The accessing form returns the value of the
generalized reference.
It may contain references to the temporary variables.
\endlist
%% 7.2.0 66
The value returned by the accessing form is
affected by execution of the storing form, but either of these
forms may be evaluated any number of times.
%% 7.2.0 67
The temporary variables and the store variables are generated names,
as if by @Funref[gensym] or @Funref[gentemp]\rm.
It is possible
to do more than one {\function setf\/} in parallel via
{\function psetf\/}, {\function shiftf\/}, and {\function rotatef\/}.
Computation
of the {\function setf\/}
method must always create new variable names; it may not return
the same ones every time.
Examples of the contents of the constituents of {\function setf\/} methods
follow.
%% 7.2.0 69
For a variable {\arg x}:
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt () }&; list of temporary variables \cr
{\tt () }&; list of value forms \cr
{\tt (g0001) }&; list of store variables \cr
{\tt (setq {\arg x} g0001) }&; storing form \cr
{\arg x }&; accessing form \cr
\noalign{\vskip -9pt}
}}
\caption{Examples of setf methods - 1}
\endfig
%% 7.2.0 70
For {\tt (car {\arg exp})}:
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt (g0002) }&; list of temporary variables \cr
{\tt ({\arg exp}) }&; list of value forms \cr
{\tt (g0003) }&; list of store variables \cr
{\tt (progn (rplaca g0002 g0003) g0003) }& ; storing form \cr
{\tt (car g0002) }&; accessing form \cr
\noalign{\vskip -9pt}
}}
\caption{Examples of setf methods - 2}
\endfig
%% 7.2.0 71
For {\tt (subseq {\arg seq s e})}:
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt (g0004 g0005 g0006) }&; list of temporary variables \cr
{\tt ({\arg seq s e}) }& ; list of value forms \cr
{\tt (g0007) }& ; list of store variables \cr
{\tt (progn (replace g0004 g0007 :start1 g0005 :end1 g0006) }& \cr
{\tt g0007) }& ; storing form \cr
{\tt (subseq g0004 g0005 g0006) }&{\tt ; accessing form} \cr
\noalign{\vskip -9pt}
}}
\caption{Examples of setf methods - 3}
\endfig
∂01-Mar-89 1257 X3J13-mailer cs proposal and straw vote
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 12:53:49 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA20108; Wed, 1 Mar 89 15:51:57 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA11442; Wed, 1 Mar 89 15:50:01 EST
Message-Id: <8903012050.AA11442@mist.>
To: baggins@ibm.com
Cc: x3j13@sail.stanford.edu
Subject: cs proposal and straw vote
Date: Wed, 01 Mar 89 15:49:59 EST
From: Dan L. Pierson <pierson@mist.encore.com>
General comments first.
I find the layout of the proposal, mainly Appendix A, confusing to the
point of uselessness. As I understand it, chapters 1 and 2 are
intended to be a general overview of the proposal, but the detailed
changes in Appendix A are what we are effectively voting on.
Unfortunately, I can't understand Appendix A without spending a long
time destroying a copy of CLtL per draft. All of the other committees
(and X3J13 as a whole) have accepted that we are writing a new
document, not rewriting Guy's book. Why do you insist on only doing
the later?
Before the Hawaii meeting, I was willing to reluctantly ignore all of
the above and just trust the Character Committee to see that Appendix
A accurately reflected the contents of chapters 1 and 2. The
combination of the revelation of deep disagreements within the
committee, and my own attempts to answer some questions by refering to
Appendix A have forced me to change my mind. I find that I cannot
understand the proposal as presented and thus cannot vote for the
contents of Appendix A. The straw ballot that follows represents my
willingness to vote for the specific issues as described in chapters 1
and 2 of the proposal provided that such a vote does not require
acceptance of the specific wording of Appendix A.
As an example of the above problems. I was unable to find anywhere in
the latest draft either the data types of character labels and
registry names or the predicates to be used to compare them. Your
replies to comments on the January draft state that these are symbols,
which seems correct, but the proposal does not appear to specify this.
Character Registries:
While the idea of character registries doesn't sound bad in principle,
I'm still not convinced that tying the first Common Lisp standard to
the output of an ISO committee which has not been (and may never be)
formed is wise. If nothing else, this approach would appear to
guarantee a period of major incompatibility for the users of any
Common Lisp implementation which provided its own set of character
registries in advance of an ISO standard.
By the way, I find the support of the ISO Prolog committee, which
seems to be being ignored by all major US and many international
Prolog implementors, rather meaningless. If you could get support from
a major, effective ISO language committee or two I might be convinced.
Moon is correct that it is (barely) possible to enumerate all the
characters in a registry without additional functionality. Never the
less, the method he proposes is far from desirable. Since I believe
that adding non-enumerable data types to Common Lisp is a bad thing, I
sould be much happier if a registry iterator were added. The following
would suffice; I'm sure that there are many acceptable alternatives:
(DO-ALL-CHARACTERS (char registry) [Macro]
body)
In particular, I would point out that requiring the available
characters to be documented is sufficient only for some users of
commercial implementations. Students, users of non-commercial
implementations, and an unfortunate number of business users have to
get by with little or no access to printed documentation.
Specific comments:
Page 8: paragraph 2 <The proposed ISO...>
Is this meant to be a proposal from X3J13 to the not-yet-existent ISO
working group? X3J13 certainly can't make a pronouncement about the
contents of a unwritten ISO Character Registry Standard.
Page 8: paragraph 3
In other words, implementations can subset character registries but
not expand them?
Straw Ballot:
Issue: CHAR-FONT-UNUSED-CHAR-BITS-NONPORTABLE
Problem: CHAR-FONT isn't used, CHAR-BITS isn't portable.
Proposal:
Eliminate of font and bit attributes.
Add rules for an implementation supporting attributes.
The only reference I can find to implementation defined attributes is
footnote 3 at the bottom of page 6. Either the "rules" mentioned
above should be added to the proposal or this part of the issue should
be dropped.
Redefine STRING-CHAR as implementation defined.
Remove CHAR-FONT-LIMIT
Remove CHAR-BITS-LIMIT
Remove INT-CHAR
Remove CHAR-BITS
Remove CHAR-FONT
Remove MAKE-CHAR
Remove CHAR-CONTROL-BIT
Remove CHAR-META-BIT
Remove CHAR-SUPER-BIT
Remove CHAR-HYPER-BIT
Remove CHAR-BIT
Remove SET-CHAR-BIT
IF: see above
Issue: CHAR-INT-ONLY-USEFUL-WHEN-ATTRIBUTES-SUPPORTED
Problem: CHAR-INT behavior is CHAR-CODE unless implementation
defined attributes are supported.
Proposal:
Remove CHAR-INT
IF: Moon agrees that this is sufficient for hashing (or I'm convinced that
he's wrong :-)).
Issue: CHARACTER-TYPE-RESTRICTIVEC
Problem: CHARACTER type doesn't allow thin & fat characters.
Proposal:
Define BASE-CHARACTER as a subtype of STRING.
Standard characters are a subset of the base
characters.
STANDARD-CHAR type is replaced by (CHARACTER :STANDARD)
Remove the semi-standard characters.
YES
Issue: STRING-TYPE-RESTRICTIVE
Problem: STRING type doesn't allow thin & fat strings.
Proposal:
Define STRING as a union type
STRING used as a type specifier for object creation
means (VECTOR CHARACTER)
All string functions operate as specified on any
string object except it is an error to insert
an extended character into a base string.
What do STRING-LESSP, etc. mean for non-standard-character strings?
Extend the COERCE function to allow coercion from
base string to extended string.
IF: the above is resolved, possibly by explictly saying it's undefined.
Issue: STRING-TYPE-ABBREVIATIONS
Problem: new types are awkward to name, want abbreviations.
Proposal:
Add BASE-STRING
Add GENERAL-STRING
YES
Issue: SIMPLE-STRING-TYPE-RESTRICTIVE
Problem: SIMPLE STRING type doesn't allow thin & fat strings.
Proposal:
Define SIMPLE-STRING as a union type
Define SIMPLE-STRING as a type specifier for object
creation means (SIMPLE-ARRAY CHARACTER (size))
YES
Issue: SIMPLE-STRING-TYPE-ABBREVIATIONS
Problem: new types are awkward to name, want abbreviations.
Proposal:
Add SIMPLE-BASE-STRING
Add SIMPLE-GENERAL-STRING
YES
Issue: FILE-EXTERNAL-REPRESENTATION
Problem: can't specify external encoding even when there are lots
Proposal:
Add :EXTERNAL-CODED-CHARACTER-FORMAT keyword to OPEN
YES
Issue: STRING-BINARY-WIDTH
Problem: Can't find out how many bytes a string will take when
written as text
Proposal:
Add :EXTERNAL-CODED-STRING-LENGTH function
YES
I think that reference to "terminal screen templates" has confused
some people without adding to the content.
Issue: CHAR-CODE-NON-PORTABLE
Problem: no way to talk about well-known external coding methods, only
internal codes
Proposal:
Add CHAR-CCS-VALUE function
YES
Issue: CHARACTER-IDENTIFICATION-NONPORTABLE
Problem: Can't portably talk about non-standard characters
Proposal:
Introduce the concept of Registries
Standardize on #\registry:id, add all-implemented-registries
Add *ALL-CHARACTER-REGISTRY-NAMES* variable
Add FIND-CHAR function
Add CHAR-LABEL function
Add CHAR-REGISTRY-NAME function
New syntax for CHARACTER type specifier
New #\label:registry character name syntax
New argument to CHARACTERP
NO: Unless the issues raised in the first part of this message are resolved.
∂01-Mar-89 1305 X3J13-mailer Section 1.7
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 1 Mar 89 13:04:43 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Wed, 1 Mar 89 16:00:20 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Wed, 1 Mar 89 15:58:25 EST
Date: Wed, 1 Mar 89 16:01 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Section 1.7
To: chapman%aitg.DEC@decwrl.dec.com
Cc: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: <8903011907.AA00298@decwrl.dec.com>
Message-Id: <19890301210123.2.BARMAR@OCCAM.THINK.COM>
Date: 1 Mar 89 07:23
From: chapman%aitg.DEC@decwrl.dec.com
A language extension is
any implementation-supplied {\word tool} that isn't explicitly defined
in this standard.
I don't like this definition. I suggest:
A language extension is any documented implementation-defined behavior
of a tool defined in this standard that varies from the behavior
described in this standard; or a documented consequence in a situation
that the standard defines as undefined, unspecified, or extendable by
the implementation.
This accomplishes several things:
- It restricts the definition to tools described in the standard.
Implementations are expected to provide their own tools in their own
packages, and I don't think these are considered extensions (this would
require an implementation to litter its documentation with "this is an
extension to Common Lisp" on nearly every page).
- It only talks about "behavior". Because of a cleanup issue voted on
in Hawaii, we already have specified that implementations are not
permitted to add tools with names in the standard-defined packages.
Because I don't think we want to consider tools in other packages as
extensions, the only thing left is the behavior of standard-defined
tools.
- It only refers to "documented" behavior. If the implementation varies
from the standard in an undocumented way it is a bug, not an extension.
And if the situation has an undocumented consequence in an undefined,
unspecified, or extendable situation, it is not an extension, it is just
an accident of the implementation.
barmar
∂01-Mar-89 1326 littell@polya.Stanford.EDU Spring Quarter RA appointments
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 89 13:26:25 PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA24634; Wed, 1 Mar 89 13:23:40 -0800
Date: Wed, 1 Mar 89 13:23:40 -0800
From: Angelina M. Littell <littell@polya.Stanford.EDU>
Message-Id: <8903012123.AA24634@polya.Stanford.EDU>
To: To:@polya.Stanford.EDU, faclist@polya.Stanford.EDU
Cc: littell@polya.Stanford.EDU
Subject: Spring Quarter RA appointments
Please send me a list of students you plan to support during the
Spring quarter, along with their source of support and percentage of
time. I need this information by March 17th. The RA appointment
forms need to be processed soon so that the students receive their
bills with the correct tuition applied.
Thank you.
--Angie
∂01-Mar-89 1335 X3J13-mailer Re: Section 1.7
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 13:35:17 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA20628; Wed, 1 Mar 89 16:31:49 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA11532; Wed, 1 Mar 89 16:29:55 EST
Message-Id: <8903012129.AA11532@mist.>
To: Barry Margolin <barmar@Think.COM>
Cc: "chapman%aitg.DEC@decwrl.dec.com"@Multimax.encore.com,
x3j13@sail.stanford.edu,
"skona%csilvax@hub.ucsb.edu"@multimax.encore.com
Subject: Re: Section 1.7
In-Reply-To: Your message of Wed, 01 Mar 89 16:01:00 -0500.
<19890301210123.2.BARMAR@OCCAM.THINK.COM>
Date: Wed, 01 Mar 89 16:29:54 EST
From: Dan L. Pierson <pierson@mist.encore.com>
- It restricts the definition to tools described in the standard.
Implementations are expected to provide their own tools in their own
packages, and I don't think these are considered extensions (this would
require an implementation to litter its documentation with "this is an
extension to Common Lisp" on nearly every page).
I'm not sure I agree with you here. Lucid certainly documents every
new "tool" as "a Lucid extension to Common Lisp" and this doesn't seem
to unduely clutter their documentation.
∂01-Mar-89 1404 @Score.Stanford.EDU:winograd@loire.stanford.edu Clancy and undergraduate teaching
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 89 14:04:19 PST
Received: from loire.stanford.edu by SCORE.STANFORD.EDU with TCP; Wed 1 Mar 89 14:03:07-PST
Received: by loire.stanford.edu (5.59/25-eef) id AA11285; Wed, 1 Mar 89 14:01:27 PDT
Date: Wed, 1 Mar 89 14:01:27 PDT
Message-Id: <8903012201.AA11285@loire.stanford.edu>
From: Terry Winograd <Winograd@csli.stanford.edu>
To: ac@score
Subject: Clancy and undergraduate teaching
I won't be able to be at the faculty meeting since we have an
undergraduate committee meeting at the same time. I wanted to express
a few thoughts relative to the appointment in general.
We have a major problem with teaching (not just undergraduate teaching)
in our department due to what I see as a temporary structural mismatch
(where temporary is on the order of 10 to 20 years). Stanford, like
other elite research institutions, has a general policy of hiring
regular faculty primarily on the basis of research strength. The
university is quite reluctant to provide regular billets to people
whose primary interest is in teaching. As a result, most of the
faculty are much more concerned with their research and not willing to
put in the time it takes to develop a consistent, coherent curriculum
and teach it well.
At the introductory service-course level, it is acceptable to hire
non-tenure-track lecturers who are excellent teachers. We have done
this quite successfully. At the graduate level, it is assumed that
only research-based professors will do an adequate job with the
material, and we just suffer with complaints about the quality of the
teaching. But in between (undergraduate beyond-intro courses) we have
a gap.
In many departments (I think this is especially typical in the
engineering school) this gap is filled by a older professors, who have
had research careers, and for various reasons don't want to continue in
that game. They turn their experience and intelligence to the concerns
of teaching, and are the mainstays for the serious curricular issues as
well as teaching many of the basic courses.
We don't have such people. I have been thinking about why this is (I
see several causal factors) and will probably get around to writing a
memo on it later. I believe that in the long run, we will normalize.
In the meantime (which as I said may be on the order of twenty years)
we need to solve the problem.
The obvious solution is to hire people who have the security and
stature (e.g., being academic council members) of the professoriate,
while having a primary focus on teaching. This is what the
professor(teaching) ranks are for, but there is a hesitancy in the
university at large to put many people in this category. I think it is
important for us (unless we have volunteers to fill the gap) to make it
clear to the university that this is a critical need and a valid
strategy. I would like to see us go in to the Dean and the Provost
with a very strong case.
My reading of Clancy is that he is well above clip level for doing
this. I'm sure we could all pick arguments with him about just how
computer science should be taught, but he has a good track record, a
good overall orientation and a focus on teaching. If he doesn't choose
to take the job if offered (which is a real possibility) we should use
this as a foot in the door to establish the need for the position, and
then move rapidly to search for someone else.
Once we have someone, we need to work out a clear understanding of
roles and status, in which real autonomy goes with formal
responsibility. That is, if he is responsible for getting the
undergraduate courses taught well, he has the autonomy (with
consultation from the rest of us) to decide what they are. But that's
getting ahead of things at this point. First we need to make the
effort to get the kind of help we need.
--t
∂01-Mar-89 1432 @Score.Stanford.EDU:wab@sumex-aim.stanford.edu rec.humor.funny, CSD students
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 89 14:32:02 PST
Received: from sumex-aim.stanford.edu by SCORE.STANFORD.EDU with TCP; Wed 1 Mar 89 14:29:17-PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA02418; Wed, 1 Mar 89 14:27:34 PST
Date: Wed, 1 Mar 1989 14:27:30 PST
From: "William A. Brown" <wab@sumex-aim.stanford.edu>
To: hk.dxk.@forsythe.stanford.edu, hk.grh@forsythe.stanford.edu,
s.street@macbeth.stanford.edu, gq.vvn@forsythe.stanford.edu,
g.gorin@macbeth.stanford.edu, hk.ixb@forsythe.stanford.edu,
hk.jjs@forsythe.stanford.edu, hk.rwb@forsythe.stanford.edu,
siegman@sierra.stanford.edu, cr.apc@forsythe.stanford.edu,
faculty@score.stanford.edu, su-etc@score.stanford.edu,
brad%looking@waterloo.edu
Cc: wab@SUMEX-AIM.Stanford.EDU, s.summer-rain@lear.stanford.edu
Subject: rec.humor.funny, CSD students
Message-Id: <CMM.0.88.604794450.wab@sumex-aim.stanford.edu>
A CALL FOR RESPONSIBLE AND ETHICAL COMPUTER SCIENCE USE
Recently you received a transmission from Oren Patashnik of the computer
science department. Oren has conducted a survey of computer science students
in an effort to draft a summary statement regarding their opinion of the
recent removal of rec.humor.funny from some Stanford computer services.
Oren's survey summary started with "The students of the computer science
department..."
We too are computer science students at Stanford. Because Oren's survey
provided no outlet for us to express WHY we oppose his statement, we are
sending this transmission to let our reasons be known. As one of the persons
who supports the University's original decision, I asked others who voted
against Oren's statement to tell me why they oppose it. What follows is a
summary of their reasons:
a) Several students pointed out that this is NOT a free speech issue.
These students noted that the University is not banning the existence of
rec.humor.funny; it is simply cancelling its subscription. Several students
compared this to the University's stance on not subscribing to pornographic
magazines.
b) One student argued that including such a file, especially a humor file,
would detract from the quality of student one would attract to such a
high-profile institution such as Stanford.
c) Another student proposed a connection between the lack of support for
the removal of the bboard with the lack of minorities period in the computer
science department.
d) Several students did not support the METHOD by which the file was
removed, but agreed that it is proper and resonsible for a university to be
able to determine what it will and will not subscribe to.
In general, all of these Stanford University Computer Science students
felt that there is a proper rationale for a University determining what it
will and will not subscribe to. In addition, many felt that this particular
humor file was not in the best interest of a multicultural university.
Final notes:
a) At least one person who did vote for the Oren's statement wrote to
tell me that he believed another process should exist for determining the
propriety of subscribing to such services.
b) I wished to send this statement with Oren's, in order to provide a
balanced picture of the feelings of the computer science department.
Apparently Oren disagreed, although he was considerate enough to send me his
mailing list.
A PERSONAL NOTE:
I sincerly hope the University takes both sides of the issue into
consideration when making its final decision. We are all members of this
diverse family. Let us not tread irresponsibly upon the feet of those least
able to defend themselves. There are so many other POSITIVE ways in which
this resource can be used to foster a diverse, dynamic academic community. I
personally disagree with Oren's belief that ridicule is the best way to fight
racism; I believe a display of truth, with truth being a realistic
presentation of a culture, is much more effective in fighting racism (or
sexism). People will never change theire racist and sexist ideas until they
have something more realistic to supplant them. I would argue that a better
use of University computer services would be to provide an avenue for the
nurturing of cultural and sexual progress, not an avenue for the perpetuation
of derogatory and harmful stereotypes. As the saying goes, beauty is as
beauty does...
How are we doing?
Sincerely,
William Brown, Jr.
MD/PhD student
∂01-Mar-89 1517 @polya.Stanford.EDU:tah@linz Theory Faculty Candidate
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 89 15:17:54 PST
Received: from linz.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA03710; Wed, 1 Mar 89 15:13:37 -0800
Received: by linz.stanford.edu (5.59/25-eef) id AA06821; Wed, 1 Mar 89 15:12:50 PDT
Message-Id: <8903012312.AA06821@linz.stanford.edu>
To: thcom@sail, csd@score, aflb-all@polya
Cc: ag@pepper
Subject: Theory Faculty Candidate
Reply-To: tah@cs.stanford.edu
Date: 01 Mar 89 15:12:40 PST (Wed)
From: Tom Henzinger <tah@linz>
Bob Cypher (Univ. of Washington) will be visiting on Thursday and
Friday, March 2-3. Please send me a message if you want to talk
with him, and/or join him for lunch/dinner.
His schedule so far:
Th 12:30 AFLB talk
4:30 Don Knuth
5:00 dinner with Don, ?
Fr
Sorry for the short notice. -t
∂01-Mar-89 1526 X3J13-mailer minor comments on letter ballot material
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Mar 89 15:26:35 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 548782; Wed 1-Mar-89 18:22:47 EST
Date: Wed, 1 Mar 89 18:22 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: minor comments on letter ballot material
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@SAIL.STANFORD.EDU, skona%csilvax@hub.ucsb.edu
Message-ID: <19890301232245.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Here are some minor comments about the material that you mailed out
with your letter ballot. This is not an official response to the
letter ballot.
I like the terms in the error-terminology proposal, however the
meanings of the terms are rather sloppily written. To take one
example, for "the consequences are unspecified", it says that
implementations are permitted to specify the consequences. However,
for "the consequences are undefined", it neither says that
implementations are permitted to specify the consequences, nor
that they are not. I noticed a few other things that might be
inconsistencies or ambiguities in these descriptions. I also
noticed that the reference sections in the letter ballot do not
actually use this error terminology, for the most part. I assume
these deficiencies are just due to the schedule, and will be
corrected before the final draft. I would certainly recommend
putting a lot of time into the exact wording of the definitions
of the error terminology, since that will have high leverage for
the understanding of the rest of the specification. CLtL suffered
greatly because we did not do this. I don't think it's effective
for the committee of the whole to argue over that exact wording,
I think it would be more appropriate for 2 or 3 people on the
editorial committee to write the whole set of descriptions at
one time in a consistent and unambiguous style. (On the subject
of implementations specifying the consequences, I see no advantage
to the standard forbidding implementations to say anything about
what the particular implementation will do in situations that
conforming programs are forbidden to depend upon.)
On page 2-12 of section 2.3, the second to last paragraph came from
something in 88-002R that said that CLtL doesn't specify some class
orderings but CLOS does. Now that CLtL and CLOS are not two separate
standards, this no longer makes sense. You don't need to talk about
classes being layered on top of a preexisting type system defined by
somebody else. Possibly you should delete all but the first sentence of
this paragraph.
The table of built-in classes on page 2-13 is missing a great many
entries. Now that cleanup issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED has
passed, the types HASH-TABLE, READTABLE, PACKAGE, PATHNAME, STREAM, and
RANDOM-STATE should be added to this table. I also believe that the
passage of FUNCTION-TYPE means that FUNCTION should be added to this
table, although I'm less confident there. Each one of these classes
has a CPL consisting of just itself and T. Do you need a separate
cleanup issue to be passed to do this?
Page 2-24 says implementations are permitted to make certain
optimizations, but does not say what they are. This paragraph
came from page 1-42 of 88-002R, which did say (or pointed to
where it is said.) Note: I have not done a line by line
comparison of this document with 88-002R and I have no intention
of doing so. This is just a discrepancy that jumped out at me.
Page 2-9 says "Updating an instance does not change its identity as
defined by the EQ function". Page 2-24 does not say "Changing the class
of an instance does not change its identity as defined by the EQ
function". My belief is that it was the intent of the CLOS committee to
say that, although 88-002R fails to say it. Do you need a separate
cleanup issue to be passed to fix this?
Here's a suggestion from one of our CLOS implementors. Would this
change (adding the word "affected") require a vote?
Page 2-9 Redefining Classes
Updating such an instance occurs at an implementation-dependent time,
but no later than the next time a slot of that instance is read or written.
I think I'd prefer if this said:
Updating such an instance occurs at an implementation-dependent time,
but no later than the next time an affected slot of that instance is
read or written.
I (Moon again) think this is a good idea.
∂01-Mar-89 1622 misha@polya.Stanford.EDU AFLB tomorrow!
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 89 16:22:43 PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA07898; Wed, 1 Mar 89 16:12:46 -0800
Date: Wed, 1 Mar 89 16:12:46 -0800
From: Michael Kharitonov <misha@polya.Stanford.EDU>
Message-Id: <8903020012.AA07898@polya.Stanford.EDU>
To: aflb-all@polya.Stanford.EDU
Subject: AFLB tomorrow!
The next AFLB is, as usual, tomorrow at 12:30 in room 352.
Bob Cypher from University of Washington will speak on
Lower and Upper Bounds on Parallel Sorting
This talk presents two results in parallel sorting. The first result is an
algorithm, called Cubesort, that sorts efficiently on a number of bounded
degree parallel computers when the number of data items exceeds the number
of processors. Let $N$ be the number of data items to be sorted, let $P$ be
the number of processors in the parallel computer and let $L = N/P$. If
$\log↑{(x)} N < L < N↑{x}$ for some constant $x$, then Cubesort sorts in
$O(L\log↑{2} N/\log L)$ time on a shuffle-exchange or cube-connected cycles
computer. This result is the fastest known for these types of computers.
The second result is a lower bound on the size of sorting networks based on
Shellsort. A comparator is a device that sorts 2 items, and a sorting
network is a hardwired collection of comparators that sorts $N$ items.
Shellsort is a well known sorting algorithm that is controlled by a sequence
of parameters called increments. Researchers have suggested that a sorting
network having $O(N\log N)$ comparators could be obtained by using Shellsort
with the correct increment sequence. All increment sequences that have been
proposed for Shellsort have been monotonic. It will be shown that any
monotonic increment sequence yields a sorting network having at least
$Omega(N\log↑{2} N/\log\log N)$ comparators.
∂01-Mar-89 1748 @Score.Stanford.EDU:hayes@arisia.xerox.com rec.humor.funny, CSD students
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 89 17:48:54 PST
Received: from arisia.Xerox.COM by SCORE.STANFORD.EDU with TCP; Wed 1 Mar 89 17:46:56-PST
Received: by arisia.Xerox.COM
(5.59++/IDA-1.2.6) id AA24440; Wed, 1 Mar 89 17:42:49 PST
Date: Wed, 1 Mar 89 17:42:49 PST
From: Pat Hayes <hayes@arisia.xerox.com>
Message-Id: <8903020142.AA24440@arisia.Xerox.COM>
To: wab@SUMEX-AIM.STANFORD.EDU
Cc: hk.dxk.@forsythe.stanford.edu, hk.grh@forsythe.stanford.edu,
s.street@macbeth.stanford.edu, gq.vvn@forsythe.stanford.edu,
g.gorin@macbeth.stanford.edu, hk.ixb@forsythe.stanford.edu,
hk.jjs@forsythe.stanford.edu, hk.rwb@forsythe.stanford.edu,
siegman@sierra.stanford.edu, cr.apc@forsythe.stanford.edu,
faculty@SCORE.STANFORD.EDU, su-etc@SCORE.STANFORD.EDU,
brad%looking@waterloo.edu, wab@SUMEX-AIM.STANFORD.EDU,
s.summer-rain@lear.stanford.edu
In-Reply-To: "William A. Brown"'s message of Wed, 1 Mar 89 14:27:30 PST <CMM.0.88.604794450.wab@sumex-aim.stanford.edu>
Subject: rec.humor.funny, CSD students
I am glad that you were able to circulate your oppposition view in
favor of electronic censorship. But some of what you say seems to
overstate your case. For a start, is it really fair to compare
rec.humor.funny to a pornographic magazine? What percentage of the
content of the newsletter has ever been in any way even slightly
racist or otherwise offensive? One would have to be a VERY sensitive
Scot to be really offended by the joke which McCarthy quoted as being
the one which apparently led to all this ruckus.
In what possible way could the University subscribing to an electronic
newsletter be considered "treading on the feet of those least able to
defend themselves" ? One would have to be actively searching for
things to offend one in order to even become aware of the thing: we
arent talking about defacing posters or assaulting people in the
street. And its not something which helps to elect KKKlan members,
its a simple source of humor. Low humor, perhaps, but thats
a separate issue: thats not sufficient reason to ban it.
Let me suggest that discussion of this poor little blackboard is
getting out of hand, especially when people are drawing veiled hints
about the possible connections between its defenders and the lack of
minority CS students...Ah, that helps to explain it, those computer
scientists are all hidden racialists; and they have a poor-quality
sense of humor as well...not the sort of people one would expect to
meet on a dark night in a high-profile institution such as Stanford,
no doubt. I expect some of them laugh at Benny Hill ( shudder ).
The trouble with your final suggestion, Mr.Brown, is this: who is to
decide what sort of stuff is OK to nurture "cultural and sexual
progress"? Will you have a committee which will check out the lines
coming into the campus and give its cultural approval? ( What will it
make of blasphemy, which is far more legitimately offensive to true
believers? ) No, this is an old idea, tried many times, that doesnt
work, because nobody has the insight, let alone the right, to make
such decisions for a society.
Pat Hayes
∂01-Mar-89 1853 X3J13-mailer Re: minor comments on letter ballot material
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 1 Mar 89 18:53:24 PST
Received: from Semillon.ms by ArpaGateway.ms ; 01 MAR 89 18:46:12 PST
Date: Wed, 1 Mar 89 18:45 PST
From: Gregor.pa@Xerox.COM
Subject: Re: minor comments on letter ballot material
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: chapman%aitg.DEC@decwrl.dec.com, x3j13@SAIL.STANFORD.EDU,
skona%csilvax@hub.ucsb.edu
Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest
In-Reply-To: <19890301232245.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890302024559.5.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no
Date: Wed, 1 Mar 89 18:22 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Here's a suggestion from one of our CLOS implementors. Would this
change (adding the word "affected") require a vote?
Page 2-9 Redefining Classes
Updating such an instance occurs at an implementation-dependent time,
but no later than the next time a slot of that instance is read or written.
I think I'd prefer if this said:
Updating such an instance occurs at an implementation-dependent time,
but no later than the next time an affected slot of that instance is
read or written.
I (Moon again) think this is a good idea.
This change makes is impossible for people to use MAKE-INSTANCES-OBSOLETE
to arrange for any future access to the slots of an instance to trap.
One of the reasons we gave for not adding an instance enumeration
mechanism was the availability of this functionality. So, I don't think
we should make this change.
I agree that the other change you suggested (change-class vs. eq) is in
line with our original intent and we should go ahead and make it. I
hope it doesn't require a vote.
Page 2-9 says "Updating an instance does not change its identity as
defined by the EQ function". Page 2-24 does not say "Changing the class
of an instance does not change its identity as defined by the EQ
function". My belief is that it was the intent of the CLOS committee to
say that, although 88-002R fails to say it. Do you need a separate
cleanup issue to be passed to fix this?
-------
∂01-Mar-89 2340 X3J13-mailer Section 2.2, part 1
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 23:38:50 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA07792; Wed, 1 Mar 89 23:36:51 PST
Message-Id: <8903020736.AA07792@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA07792; Wed, 1 Mar 89 23:36:51 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 2 Mar 89 02:32
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 2.2, part 1
%% Types - part 1
%% Type Hierarchy and Relationships
\beginsubSection{Type Hierarchy and Relationships}
Figure {\chapno--\the\capno}
depicts the @clisp\ type hierarchy and relationships.
An explanation of the
relationships of data types to each other follows.
\beginlist
%% 2.15.0 4
\itemitem{\bull} {\datatype t} is a {\word supertype} of every type whatsoever.
Every {\word object} is of type {\datatype t}.
%% 2.15.0 5
\itemitem{\bull} {\datatype Nil} is a {\word subtype} of every type whatsoever.
No {\word object} is of type {\datatype nil}.
\issue{DATA-TYPES-HIERARCHY-UNDERSPECIFIED}
The following will be left out of the standard.
%% 2.15.0 6
\itemitem{\bull} {\datatype Cons}, {\datatype symbol},
{\datatype array}, {\datatype number}, and {\datatype character}
are pairwise {\word disjoint}.
\endissue{DATA-TYPES-HIERARCHY-UNDERSPECIFIED}
%% 2.15.0 7
\itemitem{\bull} {\datatype Rational}, {\datatype float}, and {\datatype complex}
are pairwise {\word disjoint}
{\word subtypes} of {\datatype number}.
%% 2.15.0 8
\itemitem{\bull} {\datatype Integer}
and {\datatype ratio} are {\word disjoint subtypes }
of {\datatype rational}.
%% 2.15.0 10
\itemitem{\bull}
{\datatype Fixnum} and {\datatype bignum}
are {\word disjoint} {\word subtypes} of {\datatype integer}.
%% 2.15.0 12
\itemitem{\bull}
{\datatype Short-float}, {\datatype single-float}, {\datatype double-float}, and
{\datatype long-float} are {\word subtypes} of {\datatype float}.
Any two of them must be
either {\word disjoint} or identical;
if identical, then any other types between
them in the above ordering must also be identical to them
(for example, if {\datatype single-float} and {\datatype long-float}
are identical,
then {\datatype double-float} must be identical to them also).
%% 2.15.0 13
\itemitem{\bull} {\datatype Null} is a
{\word subtype} of {\datatype symbol}; the only {\word object} of
type
{\datatype null} is @nil\rm.
%% 2.15.0 14
\itemitem{\bull} {\datatype Cons} and {\datatype null}
form an {\word exhaustive partition} of
{\datatype list}.
%% 2.15.0 15
\itemitem{\bull} {\datatype Standard-char} is a {\word subtype}
of {\datatype string-char};
{\datatype string-char} is a {\word subtype} of {\datatype character}.
%% 2.15.0 16
\itemitem{\bull} {\datatype String} is a
{\word subtype} of {\datatype vector}.
{\datatype String}
is identical to {\tt (vector string-char)}, which in turn
is the same as {\tt (array string-char (*))}.
%% 2.15.0 17
\itemitem{\bull} {\datatype Bit-vector}
is a {\word subtype} of {\datatype vector}, for {\datatype bit-vector}
means {\tt (vector bit)}.
%% 2.15.0 18
\itemitem{\bull} {\tt (vector t)} and
{\datatype string}, and {\datatype bit-vector} are {\word disjoint}.
%% 2.15.0 19
\itemitem{\bull} {\datatype Vector} is a
{\word subtype} of {\datatype array};
for all types @f[x]\rm,
{\tt (vector x)} is the same as
{\tt (array x (*)).}
%% 2.15.0 20
\itemitem{\bull} {\datatype Simple-array} is a {\word subtype}
of {\datatype array}.
%% 2.15.0 21
\itemitem{\bull} {\datatype Simple-vector}, {\datatype simple-string}, and
{\datatype simple-bit-vector} are
{\word disjoint subtypes} of {\datatype simple-array}, for they
respectively mean
{\tt (simple-array t (*))}, {\tt (simple-array string-char (*))},
and {\tt (simple-array bit (*))}.
%% 2.15.0 22
\itemitem{\bull} {\datatype Simple-vector} is a {\word subtype}
of {\datatype vector},
and is
a {\word subtype} of {\tt (vector t)}.
%% 2.15.0 23
\itemitem{\bull} {\datatype Simple-string} is a
{\word subtype} of {\datatype string}.
%% 2.15.0 25
\itemitem{\bull} {\datatype Simple-bit-vector}
is a {\word subtype} of {\datatype bit-vector}.
%% 2.15.0 26
\itemitem{\bull} {\datatype Vector} and {\datatype list}
are {\word disjoint subtypes} of {\datatype sequence}.
\issue{DATA-TYPES-HIERARCHY-UNDERSPECIFIED}
The following will be left out of the standard.
%% 2.15.0 27
\itemitem{\bull} {\datatype Hash-table}, {\datatype readtable},
{\datatype package}, {\datatype pathname},
{\datatype stream}, and {\datatype random-state} are {\word pairwise disjoint}.
\endissue{DATA-TYPES-HIERARCHY-UNDERSPECIFIED}
\issue{DATA-TYPES-HIERARCHY-UNDERSPECIFIED}
\itemitem{\bull} The types {\datatype cons},
{\datatype symbol}, {\datatype array},
{\datatype number}, {\datatype character}, {\datatype hash-table},
\issue{FUNCTION-TYPE:X3J13-MARCH-88}
{\datatype function},
\endissue{FUNCTION-TYPE:X3J13-MARCH-88}
{\datatype readtable},
{\datatype package}, {\datatype pathname}, {\datatype stream},
{\datatype random-state}, and any single other type created
by {\function defstruct} or {\function defclass} are pairwise disjoint.
\endissue{DATA-TYPES-HIERARCHY-UNDERSPECIFIED}
%% 2.15.0 28
\itemitem{\bull} Any two types created by @Macref[defstruct] are {\word disjoint} unless
one is a {\word supertype} of the other by virtue of
the {\function defstruct} {\keyword :include} option.
\itemitem{\bull} Any two classes created by {\function defclass} are disjiont
unless one is a superclass of the other.
%% 2.15.0 29
\itemitem{\bull} An {\word exhaustive union} for {\datatype common} is formed by
{\datatype cons}, {\datatype symbol}, {\tt (array x)} where @f[x]
is either {\datatype t} or
a {\word subtype}
of {\datatype common}, {\datatype string}, {\datatype fixnum}, {\datatype
bignum}, {\datatype ratio},
{\datatype short-float}, {\datatype single-float}, {\datatype double-float},
{\datatype long-float},
{\tt (complex x)} where @f[x] is a
{\word subtype} of {\datatype common},
{\datatype standard-char}, {\datatype hash-table}, {\datatype readtable},
{\datatype package}, {\datatype pathname},
{\datatype stream}, {\datatype random-state}, and all types
created by the user
via @Macref[defstruct]\rm.
An implementation may not add {\word subtypes} to
{\datatype common}.
\endlist
%%kc2
\eject
\fig{
\def\IgnoreLineBreaks{\catcode'15=9 \catcode'12=9}
\def\IgnoreWhiteSpace{\catcode'11=9 \catcode'40=9 \IgnoreLineBreaks}
\def\DontIgnoreWhiteSpace{\catcode'12=\active\catcode'15=5\catcode'11=10\catcode'40=10}
\font \pipefont= circle10
\font \foofont = amr10 at 1sp
\IgnoreWhiteSpace
\let \adv=\advance
\def\he{height}
\def\wi{width}
\def\de{depth}
\newdimen \stroke
\stroke= \fontdimen8\pipefont % thickness of line in circles
\newdimen \radius \radius=6pt % radius of circles
\newdimen\irad \irad=\radius\advance\irad by -.5\stroke
\newdimen\orad \orad=\radius\advance\irad by .5\stroke
\newbox\BStrutbox
\setbox\BStrutbox\hbox{\vrule\wi0pt\he10pt\de10pt}
\def\BoxStrut{\unhcopy\BStrutbox}
!% Arrows
\newdimen\ArrowShift
\ArrowShift=\fontdimen22\tensy
\advance\ArrowShift by -0.5\stroke
\def\StrikeOut #1
{ \setbox0\hbox{#1}
\hbox to 1\wd0
{ \vrule \he\stroke\de0pt\wi\wd0
\hskip-\wd0
\unhbox0
}
}
\def\LeftArrow
{ \hskip 0.5\stroke
\StrikeOut{\lower\ArrowShift\hbox to 10pt{\tensy\char'40\hss}}
}
\def\RightArrow
{ \StrikeOut{\lower\ArrowShift\hbox to 10pt{\hss\tensy\char'41}}
\hskip 0.5\stroke
}
\def\ArrowLine
{ \StrikeOut{\hskip 10pt\hskip 0.5\stroke}
}
\def\LeftToRight
{ \let\RightSideArrow=\ArrowLine
\let\LeftSideArrow=\RightArrow
}
\def\RightToLeft
{ \let\LeftSideArrow=\ArrowLine
\let\RightSideArrow=\LeftArrow
}
\def\NoArrows
{ \let\LeftSideArrow=\ArrowLine
\let\RightSideArrow=\ArrowLine
}
!% boxes around tokens
\let\NonterminalFont=\tenrm
\newbox\TStrutbox
\setbox0\hbox{\NonterminalFont{Bg}}
\setbox\TStrutbox\hbox{\vrule\wi0pt\he\ht0\de\dp0}
\def\TextStrut{\unhcopy\TStrutbox}
\def\HorzLine{\hrule \he \stroke \de 0pt}
\def\HFil{\leaders\HorzLine\hfil}
\def\HFill{\leaders\HorzLine\hfill}
\def\Nonterminal#1
{\setbox1\vbox to 0pt{
\vss
\hbox{\TextStrut\NonterminalFont\space#1\space\hskip-\stroke}
\vss}
\hbox{
\BoxStrut
\LeftSideArrow
\lower\irad\vbox{
\TopSquare
\copy1
\BotSquare}
\RightSideArrow}
}
\def\TopSquare
{ \hbox{
\vrule\he\stroke\de\irad\wi\stroke
\vrule\he\stroke\de0pt\wi\wd1
\vrule\he\stroke\de\irad\wi\stroke}
}
\def\BotSquare
{ \hbox{
\vrule\he\orad\de0pt\wi\stroke
\vrule\he\stroke\de0pt\wi\wd1
\vrule\he\orad\de0pt\wi\stroke}
}
\def\\#1{\Nonterminal{#1}\HFil}
\def\last#1{{\def\RightSideArrow{}\Nonterminal{#1}}}
!% piping
\def\foo{\rlap{\foofont\char'40}}
\def\FulVert{\vrule \wi\stroke\foo\hskip-\stroke}
\def\TopVert{\vrule\de-\irad \wi\stroke\foo\hskip-\stroke}
\def\BotVert{\vrule\he-\orad \wi\stroke\foo\hskip-\stroke}
\def\Center#1,#2.
{\hskip\radius\foo#1\lower.5\stroke\hbox{\pipefont#2}\hskip\radius}
\def\ru{\char'10\hskip -2\radius}
\def\rd{\char'11\hskip -2\radius}
\def\ld{\char'12\hskip -2\radius}
\def\lu{\char'13\hskip -2\radius}
\def\thru{\hskip-\radius\vrule\he\stroke\de0pt\wi2\radius\hskip\radius\hskip-2\radius}
\def\Center#1,#2.
{\foo\hskip\radius#1{\pipefont#2\unskip}\hskip-\radius}
\def\LT{\Center\BotVert,\lu.}
\def\LU{\Center\FulVert,\lu.}
\def\LL{\Center\FulVert,\ld.}
\def\LB{\Center\TopVert,\ld.}
\def\LMid{\Center\TopVert\BotVert,\rd\ru\thru.}
\def\LMU{\Center\TopVert,\rd\thru.}
\def\LML{\Center\BotVert,\ru\thru.}
\def\LFD{\Center\FulVert,\ru\thru.}
\def\LS{\Center\TopVert\BotVert,\rd\ru.}
\def\RT{\Center\BotVert,\ru.}
\def\RU{\Center\FulVert,\ru.}
\def\RL{\Center\FulVert,\rd.}
\def\RB{\Center\TopVert,\rd.}
\def\RMid{\Center\TopVert\BotVert,\ld\lu\thru.}
\def\RMU{\Center\TopVert,\ld\thru.}
\def\RML{\Center\BotVert,\lu\thru.}
\def\Cross{\Center\FulVert,\thru.}
\def\LR{\Center,\thru.}
\def\TB{\Center\FulVert,.}
!% ShiftBox
\newbox\x
\newbox\y
\newbox\tempy
\newbox\z
\newbox\tempz
\def\ShiftBox#1{
\savemod
\saverulebox
\setbox\x
\vbox{ \everycr{\noalign{{\modifyrulebox\global\setbox\z\hbox{}}}}
\halign{&\setbox\x\hbox{##}
\global \setbox\z\hbox{\unhbox\z\vrule\he\ht\x\de\dp\x\wi0pt}
\unhbox\x
\cr
#1}}%
\lower\ht\y\box\x\HFil
\restoremod
\restorerulebox
}
\def\saverulebox{
\setbox\tempy\box\y
\global \setbox\y\vbox{}
\setbox\tempz\box\z
\global \setbox\z\hbox{}
}
\def\restorerulebox{
\global \setbox\y\box\tempy
\global \setbox\z\box\tempz
}
\def\topmod{}
\def\thisrow{\global\let\modifyrulebox\firstmod}
\def\firstmod{
\global\setbox\y\vbox{\hrule\he0pt\wi0pt\de\dp\z}
\global\let\modifyrulebox\latermod
}
\def\latermod{
\global\setbox\y\vbox{\unvbox\y\hrule\he\ht\z\de\dp\z\wi0pt}
}
\def\savemod{
\let\tempmod\modifyrulebox
\global \let\modifyrulebox\topmod
}
\def\restoremod{
\global\let\modifyrulebox\tempmod
}
\DontIgnoreWhiteSpace
!{\baselineskip0pt
\lineskip0pt
\LeftToRight
\IgnoreWhiteSpace
\def\ms{\os
\os\os\os}
\def\os{\omit\span}
\hbox{
\\{nil}
\ShiftBox{
\ms\ShiftBox{
\ShiftBox{
\ShiftBox{
\LT\\{fixnum}&\RT\cr
\LU\\{bignum}&\RMU\thisrow\cr
}\\{integer}&\RML\thisrow\cr
\LU\\{ratio}&\RB\cr
}\\{rational}&\RT\cr
\ShiftBox{
\LU\\{short-float}&\RT\cr
\LU\\{single-float}&\RMid\thisrow\cr
\LU\\{double-float}&\RL\cr
\LU\\{long-float}&\RB\cr
}\\{float}&\RMid\thisrow\cr
\LU\\{complex}&\RB\cr
}\\{number}&\RT\cr
\ms\LU\\{standard-char}\\{string-char}\\{character}&\RU\cr
\LU\\{null}&\os\os\os\LML\\{symbol}&\RU\cr
\LMid\\{cons}&\os\os\RMU\\{list}&\RML\\{sequence}&\RMid\thisrow\cr
\os\LL\\{simple-vector}&\LML\HFil&\RML\\{vector}&\LS&\TB\cr
\os\LL\\{simple-bit-vector}&\LFD\\{bit-vector}&\RL&\TB&\TB\cr
\os\LL\\{simple-string}&\LFD\\{string}&\RB&\TB&\TB\cr
\os\TB&\os\LB\HFil\\{simple-array}&\RMU\\{array}&\RL\cr
\ms\LL\\{function}\\{compiled-function}&\RL\cr
\ms\LL\\{stream}&\RL\cr
\ms\LL\\{hash-table}&\RL\cr
\ms\LL\\{readtable}&\RL\cr
\ms\LL\\{package}&\RL\cr
\ms\LL\\{pathname}&\RL\cr
\ms\LL\\{random-state}&\RL\cr
\ms\LB\\{structures}&\RB\cr
}
\last{t}}}
}\caption{Relationships among the Common Lisp data types}
\endfig
\eject
%%kc1
\endsubSection%{Type Hierarchy and Relationships}
\beginsubSection{Data Type Definition}
Following is a description of each @clisp\ {\word type}.
%% 2.0.0 6
\beginsubsubsection{\datatype t}
The set of all {\word objects} is specified
by @true\rm.
\beginsubsubsection{\datatype Number}
The type {\datatype number\/} is composed of the pairwise {\word disjoint}
{\datatype rational}, {\datatype float}, and {\datatype complex\/} subtypes\/.
An {\word object} of type {\datatype number\/} is called a {\datatype
number\/}.
%% 12.0.0 4
Two {\datatype numbers\/} that are {\function eql} or
{\function =} are not necessarily {\function eq}.
The contagion rules for implicit coercions of arguments in
{\word operations} follow:
\beginlist
\itemitem{\bull}
When a {\word shorter}
{\datatype floating-point} number is combined with a longer one in an
operation,
the result will be of the {\word type} of the longer
of the two {\datatype floating-point} numbers.
\issue{CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE)}
\itemitem{\bull}
For {\word functions} that combine arguments of different {\word types},
when one argument is a {\datatype rational} and the other is
a {\datatype floating-point} number,
the {\datatype rational} is first
converted to a {\datatype floating-point} number of
the same format.
For {\word functions} that compare arguments of different {\word types},
when one argument is a {\datatype rational} and the other is
a {\datatype floating-point} number, the function
{\function rational} is effectively
called to convert the {\datatype floating-point}
number to a {\datatype rational} and then an exact
comparison is performed. In the case of {\datatype complex\/}
numbers, the real and
imaginary parts are handled individually.
\endissue{CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE)}
\itemitem{\bull}
When a non-{\datatype complex\/}
number meets a {\datatype complex\/} number, the non-{\datatype complex\/}
number is in effect first converted to a
{\datatype complex\/} number by providing an
imaginary part of {\tt $0$}.
\endlist
%% 12.5.3 1
Many of the irrational and transcendental functions are multiply defined
in the complex domain; for example, there are in general an infinite
number of complex values for the logarithm function. In each such
case, a principal value must be chosen for the function to return.
In general, such values cannot be chosen so as to make the range
continuous; lines in the domain
called branch cuts must be defined, which in turn
define the discontinuities in the range.
%% 12.5.3 2
@clisp\ defines the branch cuts, principal values, and boundary
conditions for the complex functions following
@apl\rm.
%% 12.7.0 1
%% 12.7.0 2
Logical operations require {\datatype integers}
as arguments; an error of type {\datatype type-error}
is signalled if a non-{\datatype integer} is supplied
as an argument.
{\datatype Integer} arguments to logical operations are treated as if
they were represented in two's-complement notation.
Internally an implementation
may or may not use a two's-complement representation.
%% 12.8.0 2
The byte-manipulation {\word forms}
use {\word objects} called byte specifiers to
designate a specific byte position within an {\datatype integer}.
The representation of a byte specifier is implementation-dependent ---
it may or may not be a {\datatype number}.
The function {\function byte} will construct a byte specifier,
and the byte-manipulation {\word forms} will accept it.
The following figures contain lists of {\word tools} applicable to
{\datatype numbers}.
Figure {\chapno--\the\capno} lists the number predicate and comparison
{\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt zerop }&{\tt plusp }&{\tt minusp }\cr
{\tt oddp }&{\tt evenp } &{\tt = }\cr
{\tt /= }&{\tt < } &{\tt > }\cr
{\tt <= }&{\tt >= } &{\tt max }\cr
{\tt min} & & \cr
\noalign{\vskip -9pt}
}}
\caption{Number tools - 1}
\endfig
Figure {\chapno--\the\capno} lists the {\word tools} for arithmetic operations.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt + }&{\tt - } &{\tt * }\cr
{\tt / }&{\tt 1+ } &{\tt 1- }\cr
{\tt incf }&{\tt decf } &{\tt conjugate }\cr
{\tt gcd }&{\tt lcm } & \cr
\noalign{\vskip -9pt}
}}
\caption{Number tools - 2}
\endfig
Figure {\chapno--\the\capno} lists the {\word tools}
for exponential, logarithmic, and trigonometric operations.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt exp }&{\tt expt } &{\tt log }\cr
{\tt sqrt }&{\tt isqrt } &{\tt abs }\cr
{\tt phase }&{\tt signum } &{\tt sin }\cr
{\tt cos }&{\tt tan } &{\tt cis }\cr
{\tt asin }&{\tt acos } &{\tt atan }\cr
{\tt pi }&{\tt sinh } &{\tt cosh }\cr
{\tt tanh }&{\tt asinh } &{\tt acosh }\cr
{\tt atanh }& &\cr
\noalign{\vskip -9pt}
}}
\caption{Number tools - 3}
\endfig
Figure {\chapno--\the\capno} lists the {\word tools}
for type conversion and component extraction operations.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt float }&{\tt rational} &{\tt rationalize } \cr
{\tt numerator} & {\tt denominator }& {\tt floor} \cr
{\tt ceiling} & {\tt truncate} & {\tt round} \cr
{\tt mod} & {\tt rem} & {\tt ffloor}\cr
{\tt fceiling} & {\tt ftruncate} & {\tt fround}\cr
{\tt decode-float} & {\tt scale-float} & {\tt float-radix}\cr
{\tt float-sign} & {\tt float-digits} & {\tt float-precision}\cr
{\tt integer-decode-float} & {\tt complex} & {\tt realpart}\cr
{\tt imagpart} & & \cr
\noalign{\vskip -9pt}
}}
\caption{Number tools - 4}
\endfig
Figure {\chapno--\the\capno} lists the logical operation {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt logior} & {\tt logxor} & {\tt logand} \cr
{\tt logeqv} & {\tt lognand} & {\tt lognor} \cr
{\tt logandc1} & {\tt logandc2 }&{\tt logorc1 } \cr
{\tt logorc2 } & {\tt boole }&{\tt boole-clr }\cr
{\tt boole-set } & {\tt boole-1 }&{\tt boole-2 }\cr
{\tt boole-c1 } & {\tt boole-c2 }&{\tt boole-and }\cr
{\tt boole-ior } & {\tt boole-xor }&{\tt boole-eqv }\cr
{\tt boole-nand } & {\tt boole-nor }&{\tt boole-andc1 }\cr
{\tt boole-andc2 } & {\tt boole-orc1 }&{\tt boole-orc2 }\cr
{\tt lognot } & {\tt logtest }&{\tt logbitp }\cr
{\tt ash } & {\tt logcount} & {\tt integer-length }\cr
\noalign{\vskip -9pt}
}}
\caption{Number tools - 5}
\endfig
Figure {\chapno--\the\capno} lists the byte manipulation {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt byte} &{\tt byte-size} & {\tt byte-position}\cr
{\tt ldb} & {\tt ldb-test} & {\tt mask-field} \cr
{\tt dpb} & {\tt deposit-field} & \cr
\noalign{\vskip -9pt}
}}
\caption{Number tools - 6}
\endfig
Figure {\chapno--\the\capno} lists the implementation-dependent parameters.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt most-positive-fixnum }& {\tt most-negative-fixnum }\cr
{\tt most-positive-short-float } &{\tt least-positive-short-float} \cr
{\tt least-negative-short-float} & {\tt most-negative-short-float} \cr
{\tt most-positive-single-float } & {\tt least-positive-single-float} \cr
{\tt least-negative-single-float} & {\tt most-negative-single-float} \cr
{\tt most-positive-double-float} & {\tt least-positive-double-float} \cr
{\tt least-negative-double-float} & {\tt most-negative-double-float} \cr
{\tt most-positive-long-float} &{\tt least-positive-long-float} \cr
{\tt least-negative-long-float} & {\tt most-negative-long-float} \cr
{\tt short-float-epsilon} & {\tt single-float-epsilon} \cr
{\tt double-float-epsilon} & {\tt long-float-epsilon} \cr
{\tt short-float-negative-epsilon} & {\tt single-float-negative-epsilon}\cr
{\tt double-float-negative-epsilon}& {\tt long-float-negative-epsilon} \cr
\noalign{\vskip -9pt}
}}
\caption{Number tools - 7}
\endfig
\beginsubsubsection{\datatype Rational}
The type {\datatype
rational} is composed of the {\word disjoint}
{\datatype integer} and {\datatype
ratio} subtypes.
An {\word object} of type {\datatype rational\/} is called a {\datatype
rational}.
%% 12.1.0 2
The following rules apply to {\datatype rational} computations.
\beginlist
\itemitem {--} Rational computations cannot overflow in the usual sense
(though there may not be enough storage
to represent one), since
{\datatype integers} and {\datatype ratios}
may in principle be of any magnitude.
%% 2.1.2 1
\itemitem {--} The representation of a
{\datatype rational} number is as the ratio of two
integers, the numerator and denominator, where the greatest common divisor of
the numerator and denominator is one, and where the denominator is positive
and greater than one. If the value of a {\datatype rational} is
an {\datatype integer}, it is
represented as an integer.
%% 2.1.2 2
%% 12.1.0 5
\itemitem{--} If any computation produces
a result that is a {\datatype ratio} of
two {\datatype integers} such that the denominator evenly divides the
numerator, then the result is converted to the equivalent
{\datatype integer}.
%% 12.1.0 3
\itemitem{--} When
{\datatype rational} and {\datatype floating-point} numbers
are compared or combined by
a numerical {\word function},
the {\datatype rational}
is first converted to a {\datatype floating-point} number of
the same format. For {\word forms} such as {\function +}
that take more than two arguments,
it is permitted that part of the operation be carried out exactly using
{\datatype rationals}
and the rest be done using floating-point arithmetic.
%% 12.5.0 4
\itemitem{--}
When the arguments to
a mathematical
{\word function} are all {\datatype rational} and the true mathematical result
is also (mathematically) rational, then unless otherwise noted
an implementation is free to return either an accurate
{\datatype rational} result
or a {\datatype single-float} approximation.
If the arguments are all {\datatype rational}
but the result cannot be expressed
as a {\datatype rational} number, then a {\datatype single-float}
approximation is always returned.
\endlist
∂01-Mar-89 2355 X3J13-mailer Section 2.2 - part 2
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 89 23:55:24 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA08620; Wed, 1 Mar 89 23:53:21 PST
Message-Id: <8903020753.AA08620@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA08620; Wed, 1 Mar 89 23:53:21 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 2 Mar 89 02:51
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 2.2 - part 2
%%Types - part 2
\beginsubsubsection{\datatype Ratio}
An {\word object} of type {\datatype ratio\/} (a {\datatype ratio}) is the
mathematical ratio of two {\datatype integers}.
%% 2.1.1 1
\beginsubsubsection{\datatype Integer}
The type {\datatype integer} is composed of
{\word disjoint} {\datatype
fixnum} and {\datatype bignum} subtypes.
An {\word object} of type {\datatype integer\/} (an {\datatype integer}) is a
mathematical integer. There is no limit on the magnitude of an
{\datatype
integer}.
Properties of integers follow:
\beginlist
\itemitem{--} 0 = $-0$
\itemitem{--} The default printed
representation and interpretation for an {\datatype
integer} is decimal.
\endlist
%% 2.1.1 2
\beginsubsubsection{\datatype Fixnum}
An {\word object} of type {\datatype fixnum} (a {\datatype fixnum}) is an
an
{\datatype integer} whose value is between
{\function most-negative-fixnum} and
{\function most-positive-fixnum} inclusive.
Exactly which {\datatype integers} are
{\datatype fixnums} is implementation-dependent.
\beginsubsubsection{\datatype Bignum}
An {\word object} of type {\datatype bignum} (a {\datatype bignum})
is an
{\datatype integer} outside the {\datatype fixnum} range.
\beginsubsubsection{\datatype Float}
The type {\datatype float} is composed of the
{\word disjoint} or identical {\datatype short-float},
{\datatype single-float},
{\datatype double-float}, and {\datatype long-float} subtypes.
An {\word object} of type {\datatype float} (a {\datatype floating}-point
number)
is a (mathematical)
{\datatype rational} of the form
{\it s@centerdot f@centerdot $b↑{e-p}$},
where {\it s} is +1 or @minussign 1, the {\it sign}\rm;
{\it b} is an {\datatype integer}
greater than 1, the {\it base} or {\it radix} of the representation;
{\it p} is a positive {\datatype integer},
the {\it precision} (in base-{\it b} digits) of the floating-point {\datatype
number};
{\it f} is a positive {\datatype integer}
between {\it $b↑{p-1}$} and
{\it $b↑p-1$} (inclusive), the significand;
and {\it e} is an {\datatype integer}, the exponent.
The value of {\it p} and the range of {\it e}
depends on the implementation and on the type of {\datatype floating-point} number
within that implementation.
An {\word object} of type {\datatype short-float\/} is called a {\datatype
short-float}.
An {\word object} of type {\datatype single-float\/} is called a {\datatype
single-float}.
An {\word object} of type {\datatype double-float\/} is called a {\datatype
double-float}.
An {\word object} of type {\datatype long-float\/} is called a {\datatype
long-float}.
Properties of {\datatype floating-point} numbers follow:
\beginlist
\itemitem{--} There is a {\datatype floating-point} number
whose value is zero.
\itemitem{--} If the numeric representation of
{\datatype floating-point} numbers
allows ``minus zero'', it will exist.
\itemitem{--} {\tt $0.0$ = $-0.0$} if there is no minus zero.
\endlist
%% 2.1.3 6
Intermediate between {\datatype short-float} and {\datatype long-float}
are
{\datatype single-float} and {\datatype double-float}.
The precise definition of these categories is implementation-dependent.
The precision (measured in ``bits'', computed as {\it p} log$\sub 2${\it b}\rm)
and the exponent size (also measured in ``bits'', computed as
log$\sub 2$ (maximum exponent value + 1)) is recommended
to be at least as great
as the values in Figure {\chapno--\the\capno}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip
\dimen0 plus .5 fil&#\hfil\cr
\noalign{\vskip -9pt}
\hfil\bf Format &Minimum Precision &Minimum Exponent Size \cr
\noalign{\vskip 2pt\hrule\vskip 2pt}
Short&13 bits&5 bits\cr
Single&24 bits&8 bits\cr
Double&50 bits&8 bits\cr
Long&50 bits&8 bits\cr
\noalign{\vskip -9pt}
}}
\caption{Recommended Minimum Floating-Point Precision and Exponent Size}
\endfig
%% 2.1.3 10
%% 2.1.3 11
%% 2.1.3 18
There may be fewer than four internal
representations for {\datatype floating-point} numbers.
If there are fewer distinct representations, the following fules apply:
\beginlist
\itemitem{--} If there is only one, it is of
the type {\datatype single-float}.
In this representation, an {\word object} is simultaneously of types
{\datatype single-float, double-float, short-float}, and {\datatype
long-float}.
\itemitem{--} Two internal representations can be arranged in either of the
following ways:
\beginlist
\itemitem{\bull} Two {\word types} are provided: {\datatype single-float} and
{\datatype short-float}. An {\word object} is simultaneously of types
{\datatype single-float, double-float}, and {\datatype long-float}.
\itemitem{\bull} Two {\word types} are provided: {\datatype single-float} and
{\datatype double-float}. An {\word object} is simultaneously of types
{\datatype single-float} and {\datatype short-float}, or
{\datatype double-float} and {\datatype long-float}.
\endlist
\itemitem{--} Three internal representations can be arranged in either
of the following ways:
\beginlist
\itemitem{\bull} Three {\word types} are provided: {\datatype short-float},
{\datatype single-float}, and
{\datatype double-float}. An {\word object} can
simultaneously be of type {\datatype double-float} and {\datatype long-float}.
\itemitem{\bull} Three {\word types} are provided:
{\datatype single-float}, {\datatype double-float},
and {\datatype long-float}. An {\word object} can simultaneously
be of types {\datatype single-float} and {\datatype short-float}.
\endlist
\endlist
Figure {\chapno--\the\capno} contains
examples of printed {\datatype floating-point} numbers:
The following rules apply to floating point computations.
%% 12.1.0 1
%% 12.5.0 3
\beginlist
\itemitem{--}
Computations with {\datatype floating-point} numbers are only approximate,
although they are described as if the results
were mathematically accurate.
Two mathematically identical
expressions may be computationally different because of errors
inherent in the floating-point approximation process.
The precision of a {\datatype floating-point} number is not necessarily
correlated with the accuracy of that number.
For instance, 3.142857142857142857 is a more precise approximation
to $\pi$ than 3.14159, but the latter is more accurate.
The precision refers to the number of bits retained in the representation.
When an operation combines a {\datatype short-float} with a
{\datatype long-float},
the result will be a {\datatype long-float}.
@clisp\ {\word functions} assume that the accuracy of
arguments to them does not exceed their precision. Therefore
when two small {\datatype floating-point} numbers
are combined, the result is a small {\datatype floating-point} number.
@clisp\ {\word functions}
never convert automatically from a larger size to a smaller one.
%% 12.1.0 2
\itemitem{--} An error of type {\datatype floating-point-overflow}
or {\datatype floating-point-underflow} should be signalled if a
floating-point computation causes exponent overflow or underflow.
%% 12.1.0 5
\itemitem{--}
The result of a numerical function
is a {\datatype floating-point} number of the largest format among all the
floating-point arguments to the {\word function}.
\endlist
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip
\dimen0 plus .5 fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt 0.0} & ;Floating-point zero in default format
\cr
{\tt 0E0 } & ;Also floating-point zero in default format
\cr
{\tt -.0 } & ;This may be a zero or a minus zero, \cr
& ; depending on the implementation \cr
{\tt 0.} & ;The integer zero, not a floating-point
number! \cr
{\tt 0.0s0 } & ;A floating-point zero in short format
\cr
{\tt 0s0 } & ;Also a floating-point zero in short format
\cr
{\tt 6.02E+23} & ;Avogadro's number, in default format
\cr
{\tt 602E+21} & ;Also Avogadro's number, in default format
\cr
%3.010299957f-1 & ;$log_10$2, in single format \cr
}}
\caption{Examples of Floating-point numbers}
\endfig
%% 2.1.4 1
%% 2.1.4 4
\beginsubsubsection{\datatype Complex}
An {\word object} of type {\datatype complex\/} (a {\datatype complex\/} number)
is represented in Cartesian form, with a real part and an imaginary
part each of which is not a
{\datatype complex\/} number
(i.e. an {\datatype integer}, {\datatype ratio}, or {\datatype floating-point}
number). The parts of a {\datatype complex\/} number
are not necessarily {\datatype floating-point} numbers
but both parts must
be of the same {\word type}: either both are
{\datatype rationals}, or both are
of the same {\datatype floating-point} number {\word subtype}.
When constructing
a {\datatype complex\/} number, if the specified parts are not the same
{\word type}, the parts will be converted to be the same {\word type}
internally (i.e. the {\datatype rational} part
will be converted to
a {\datatype floating-point} number).
An {\word object} of type
{\tt (complex rational)}
will be converted internally and represented thereafter as
a {\datatype rational}
if its imaginary part is an
{\datatype integer} whose value is 0.
%% 12.1.0 6
The following rules apply to {\datatype complex\/} computations:
\beginlist
\itemitem{--}
Except during the execution of irrational and
transcendental {\word forms}, {\datatype complex\/}
numbers never result from a numerical {\word form}
unless one or more of the
arguments is {\datatype complex\/}.
\itemitem{--}
When a non-{\datatype complex\/} number and
a {\datatype complex\/} number are both part of a computation,
the non-{\datatype complex\/}
number is first converted to a {\datatype complex\/} number by providing an
imaginary part of @f[0]\rm.
%% 12.1.0 8
\itemitem{--}
If the result of any computation would be a {\datatype complex\/}
number whose real part is of type {\datatype rational} and whose imaginary
part is zero, the result is
converted to a non-{\datatype complex\/} number
of type {\datatype rational} composed of the
real part.
This rule does not apply to {\datatype complex\/} numbers whose parts
are {\datatype floating-point} numbers.
For example, @f[\#C(5 0)] and @f[5] are not
distinct values in @clisp\ (they are always {\function eql});
@f[\#C(5.0 0.0)] and @f[5.0] are always distinct values in @clisp\
(they are never {\function eql}, although they are {\function equalp}).
\endlist
%% 12.5.3 17
Figure {\chapno--\the\capno} lists
the identities that are obeyed
throughout the applicable portion of the complex domain, even on
the branch cuts:
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0
plus 1fil&#\hfil\cr
\noalign{\vskip -9pt}
sin i z = i sinh z & sinh i z = i sin z& arctan i z = i arctanh z \cr
cos i z = cosh z & cosh i z = cos z & arcsinhi z = i arcsin z \cr
tan i z = i tanh z & arcsin i z = i arcsinh z & arctanh i z = i arctan z \cr
\noalign{\vskip -9pt}
}}
\caption{Trigonometric Identities for Complex Domain}
\endfig
%% 2.2.4 1
\beginsubsubsection{\datatype Character}
The type {\datatype character} has a
{\word subtype}
of {\datatype string-char}.
An {\word object} of type {\datatype character} (a {\datatype character})
has three non-negative attributes: code, bits, and font.
%% 13.0.0 3
%% 13.0.0 4
The following rules apply to {\datatype characters}:
\beginlist
\itemitem{--} Two {\datatype characters}
that are {\function eql}, {\function char=}, or {\function char-equal}
are not necessarily {\function eq}.
%% 13.1.0 1
\itemitem{--} Every {\datatype character}
has three attributes: code, bits, and font.
The code attribute is intended to distinguish among the printed glyphs
and formatting functions for {\datatype characters}.
The bits attribute allows extra
flags to be associated with a {\datatype character}. The font attribute permits
a specification of the style of the glyphs (such as italics).
Each of these attributes is a non-negative
{\datatype integer}.
%% 13.5.0 1
\itemitem{--} Four bits of the bits attribute are defined:
Control, Meta, Hyper, and Super.
Each @clisp\ implementation provides these bit definitions for compatibility,
even if it does not support the bits.
\itemitem{--} The total ordering on
{\datatype characters} is guaranteed to have the following
properties:
\beginlist
%% 13.2.0 27
\itemitem{\bull} If two {\datatype characters}
have the same bits and font attributes,
then their ordering by {\function char<} is consistent with the numerical
ordering by the predicate {\function <} on their code attributes.
%% 13.2.0 28
\itemitem{\bull} If two {\datatype characters}
differ in any attribute (code, bits, or font), then they
are different.
%% 13.2.0 29
\itemitem{\bull} The total ordering is not necessarily the same as the total
ordering on the {\datatype integers}
produced by applying @Funref[char-int] to the
{\datatype characters}.
%% 13.2.0 30
\itemitem{\bull}
While alphabetic {\datatype characters} of a given case must be
properly ordered, they need not be contiguous; it is permitted for
uppercase and lowercase letters to be interleaved.
Thus @f[(char<= \#{\char '134}a x
\#{\char '134}z)] is not
a valid way of determining whether or not @f[x] is a
lowercase letter.
%% 13.2.0 34
\itemitem{\bull}
The ordering may depend on the font information. For example, an implementation
might decree that {\tt (char-equal \#{\char '134}p \#{\char '134}{\it p})}
be true, but that
{\tt (char-equal \#{\char '134}p \#{\char '134}$\pi$)}
be false (where {\tt \#{\char '134}$\pi$} is a
lowercase @f[p] in some font). Assuming italics to be in font 1
and the Greek alphabet in font 2, this is the same as saying that
{\tt (char-equal \#0{\char '134}p \#1{\char '134}p)}
may be true and at the same time
{\tt (char-equal \#0{\char '134}p \#2{\char '134}p)} may be false.
\endlist
%% 13.2.0 25
%% 13.2.0 26
The standard alphanumeric characters obey the following partial ordering:
@Lisp
A<B<C<D<E<F<G<H<I<J<K<L<M<N<O<P<Q<R<S<T<U<V<W<X<Y<Z
a<b<c<d<e<f<g<h<i<j<k<l<m<n<o<p<q<r<s<t<u<v<w<x<y<z
0<1<2<3<4<5<6<7<8<9
either 9<A or Z<0
either 9<a or z<0
@Endlisp
This implies that alphabetic ordering holds within each case (upper and
lower), and that the digits as a group
are not interleaved with letters. However, the ordering
or possible interleaving of
uppercase letters and lowercase letters is unspecified.
The following figures contain lists of {\word tools} applicable to {\datatype
characters}.
Figure {\chapno--\the\capno} lists the {\datatype character}
attribute and predicate {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt char-code-limit }&{\tt char-font-limit }&{\tt char-bits-limit }\cr
{\tt standard-char-p }&{\tt graphic-char-p }&{\tt string-char-p }\cr
{\tt alpha-char-p }&{\tt upper-case-p }&{\tt lower-case-p }\cr
{\tt both-case-p }&{\tt digit-char-p }&{\tt alphanumericp }\cr
{\tt char= }&{\tt char/= }&{\tt char< }\cr
{\tt char> }&{\tt char<= }&{\tt char>= }\cr
{\tt char-equal }&{\tt char-not-equal }&{\tt char-lessp }\cr
{\tt char-greaterp }&{\tt char-not-greaterp }&{\tt char-not-lessp }\cr
\noalign{\vskip -9pt} }}
\caption{Character tools - 1}
\endfig
Figure {\chapno--\the\capno} lists the
{\datatype character} construction, conversion, and control-bit {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt char-code }&{\tt char-bits }&{\tt char-font }\cr
{\tt code-char }&{\tt make-char }&{\tt character }\cr
{\tt char-upcase }&{\tt char-downcase }&{\tt digit-char }\cr
{\tt char-int }&{\tt int-char }&{\tt char-name }\cr
{\tt name-char }&{\tt char-control-bit }&{\tt char-meta-bit }\cr
{\tt char-super-bit }&{\tt char-hyper-bit }&{\tt char-bit }\cr
{\tt set-char-bit }& & \cr
\noalign{\vskip -9pt} }}
\caption{Character tools - 2}
\endfig
%% 2.2.5 1
\beginsubsubsection{\datatype String-char}
The type {\datatype string-char} has a {\word subtype} of {\datatype
standard-char}.
An {\word object} of type {\datatype string-char} (a {\datatype string-char})
is a {\datatype character\/} whose bit and font
attributes are {\datatype integers}
whose values are 0.
\beginsubsubsection{\datatype Standard-char}
{\word Objects} of type {\datatype standard-char} ({\datatype standard-chars})
are listed
in ``Object Syntax''.
%% 2.3.0 1
%% 2.3.0 2
\beginsubsubsection{\datatype Symbol}
An {\word object} of type {\datatype symbol} (a {\datatype symbol})
is a data structure
composed of a print namestring,
a package name, and a
property list. A {\datatype symbol} may be retrieved from
a {\datatype package} given a print name.
{\datatype Symbols} can be interned or uninterned in a {\datatype package}.
%% 11.0.0 11
To intern a {\datatype symbol} in a {\datatype package} means to cause the
{\datatype symbol}
to be accessible in the {\datatype package} if it were not already.
See {\function intern}.
If the {\datatype symbol} were previously unowned, then the
{\datatype package} it is being
interned in becomes its owner (home package); but
if the {\datatype symbol}
was previously owned by another {\datatype package}, that other {\datatype
package}
continues to own the {\datatype symbol}.
%% 10.3.0 2
%% 10.3.0 3
Interned symbols are created automatically by {\function intern};
If a given print name does not have a corresponding
{\datatype symbol} in the specified or
inherited {\datatype packages}, a {\datatype symbol} is
created for that print name.
the first time
something (such as {\function read})
asks the package system for a {\datatype symbol} with a given print name,
that {\datatype symbol} is automatically created.
%% 11.0.0 12
To unintern a {\datatype symbol} from a
{\datatype package} means to cause it to be not
present and, additionally, to make the {\datatype symbol} uninterned if the
{\datatype package} is the {\datatype symbol's} home package.
See @Funref[unintern]\rm.
%% 10.3.0 1
{\datatype Symbols} have the following
components, the first three of which are user-visible.
%% 10.0.0 3
%% 10.0.0 4
%% 10.1.0 1
%% 10.1.0 2
%% 10.1.0 3
\beginlist
\itemitem{\bf Property list}
The property list is an even-length
{\datatype list} of zero or more
elements
whose even-numbered components (calling the first component zero)
are indicators (no duplicates on the same
property list are allowed)
and whose odd-numbered components are {\word objects}.
The property list of a {\datatype symbol}
may be destructively replaced.
A property-value pair in the property list may be added or updated.
%% 10.1.0 4
When a {\datatype symbol} is created, its property list is initially empty.
Properties are created by using {\function setf} of @Macref[get]\rm.
Any form acceptable to {\function setf\/}
as a {\word
generalized reference} can be used to store the property list.
%% 10.0.0 5
%% 10.2.0 1
\itemitem{\bf Print name}
The print name is a {\datatype string},
used to identify the {\datatype symbol}.
Every
{\datatype symbol} has a print name, and that
name can not be altered.
The print name is used as the external representation of the
{\datatype symbol}.
If the {\datatype characters} in the {\datatype string}
of the print name are typed in to {\function read}
(with suitable escape conventions for certain characters),
it is interpreted as a reference to that {\datatype symbol}
(if it is {\word interned}); and if the {\datatype symbol}
is printed, {\function print} outputs the
print name.
Given the print name of a {\datatype symbol}
as a {\datatype string} the
{\datatype symbol} can be obtained.
Every time a {\datatype symbol} with a certain print name is referenced,
the same ({\function eq}) {\datatype symbol } is returned.
{\datatype Symbols} are organized into
{\datatype packages}, and all the {\datatype symbols}
in a {\datatype package} are uniquely
identified by print name.
A {\datatype symbol\/}'s print name can be composed
of any {\datatype string-char}. Space and parenthesis characters
must be preceded by an
escape character in order to be a part of a {\datatype symbol\/}'s print name.
A {\datatype symbol\/}'s print name must contain escape characters if
\beginlist
\itemitem{\bull} It would be composed of only periods
(.).
\itemitem{\bull} It would be syntactically identical to a
{\datatype number}.
\endlist
Any double quote in the name
of a {\datatype symbol} written using vertical-bar notation need not be
preceded by a @bsl.
%% 10.0.0 4
%% 10.3.0 4
%% 11.0.0 8
%% 11.0.0 10
%% 11.0.0 28
\itemitem{Package cell}
The package cell
contains a pointer to the {\datatype symbol's}
home {\datatype package}, if
it is interned in and owned by any {\datatype package},
or @false\ if it is uninterned (not owned by a {\datatype package}).
The package cell
may be accessed by @Funref[symbol-package]\rm.
A {\datatype symbol} may
appear in many {\datatype packages}, but it can have at most
one home {\datatype package}.
The same print name may refer to different {\datatype symbols} in
different {\datatype packages}.
%% 10.0.0 8
\itemitem{Other components}
A {\datatype symbol} may have other components for use by the
implementation.
\endlist
Following is the list of
{\word tools} that are applicable to the property list of
{\datatype symbols}: {\tt get}, {\tt remprop},
{\tt symbol-plist}, {\tt getf}, {\tt remf}, and
{\tt get-properties}.
The function {\tt symbol-name} is used to access the print name of
a symbol.
Following is the list of
{\word tools} that are applicable to creating
{\datatype symbols}: {\tt make-symbol}, {\tt copy-symbol},
{\tt gensym}, {\tt gentemp}, {\tt symbol-package}, and
{\tt keywordp}.
∂02-Mar-89 0008 X3J13-mailer Section 2.2 - part 3
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 2 Mar 89 00:08:35 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA09450; Thu, 2 Mar 89 00:06:40 PST
Message-Id: <8903020806.AA09450@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA09450; Thu, 2 Mar 89 00:06:40 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 2 Mar 89 03:05
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 2.2 - part 3
%%Types - part 3
\beginsubsubsection{\datatype Null}
The only {\word object} of type {\datatype null\/} is @nil\rm.
\beginsubsubsection{\datatype Sequence}
The type {\datatype sequence} has
{\datatype vector} and {\datatype list}
as {\word disjoint subtypes}.
An {\word object} of type {\datatype sequence\/} is called a {\datatype
sequence}.
Figure {\chapno--\the\capno} lists the {\datatype sequence} {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt elt }&{\tt subseq }&{\tt copy-seq }\cr
{\tt length }&{\tt reverse }&{\tt nreverse }\cr
{\tt make-sequence }&{\tt concatenate }&{\tt map }\cr
{\tt some }&{\tt every }&{\tt notany }\cr
{\tt notevery }&{\tt reduce }&{\tt fill }\cr
{\tt replace }&{\tt remove }&{\tt remove-if }\cr
{\tt remove-if-not }&{\tt delete }&{\tt delete-if }\cr
{\tt delete-if-not }&{\tt remove-duplicates }&{\tt delete-duplicates }\cr
{\tt substitute }&{\tt substitute-if }&{\tt substitute-if-not }\cr
{\tt nsubstitute }&{\tt nsubstitute-if }&{\tt nsubstitute-if-not }\cr
{\tt find }&{\tt find-if }&{\tt find-if-not }\cr
{\tt position }&{\tt position-if }&{\tt position-if-not }\cr
{\tt count }&{\tt count-if }&{\tt count-if-not }\cr
{\tt mismatch }&{\tt search }&{\tt sort }\cr
{\tt stable-sort }&{\tt merge }&\cr
\noalign{\vskip -9pt} }}
\caption{Sequence tools}
\endfig
%% 14.0.0 19
Whenever a {\datatype sequence} function must construct and return
a new {\datatype vector}, it always returns a {\datatype simple-vector}.
In particular, any {\datatype strings} constructed
will be {\datatype simple-strings}.
%% 2.5.1 1
\beginsubsubsection{\datatype Vector}
The type {\datatype vector} has {\word subtypes} {\datatype simple-vector,
string}, and {\datatype bit-vector}.
An {\word object} of type {\datatype vector}
(a {\datatype vector}) is a
one-dimensional {\datatype array\/}.
\beginsubsubsection{\datatype Simple-vector}
An {\word object} of type {\datatype simple-vector}
(a {\datatype simple-vector}) is
a {\datatype vector}
that is not displaced to another {\datatype vector},
has no
{\word fill pointer},
is able to hold elements of any {\word type},
and is not to have its size adjusted dynamically after
creation.
\beginsubsubsection{\datatype Bit-vector}
An {\word object} of type {\datatype bit-vector}
(a {\datatype bit-vector})
is a
{\datatype vector} composed of bits.
The type {\datatype bit-vector} has the type {\datatype simple-bit-vector}
as its {\word subtype}.
\beginsubsubsection{\datatype Simple-bit-vector}
An {\word object} of type {\datatype simple-bit-vector}
(a {\datatype simple-bit-vector}) is
a {\datatype bit-vector} that is not displaced to another
{\datatype bit-vector},
has no {\word fill pointer},
and is not to have its size adjusted dynamically after
creation.
%% 2.5.2 1
%% 18.0.0 3
\beginsubsubsection{\datatype String}
An {\word object} of type {\datatype string}
(a {\datatype string}) is
a {\datatype vector} whose
elements are {\datatype string-chars\/}.
{\datatype Simple-string} is a {\word subtype} of {\datatype string}.
Figure {\chapno--\the\capno}
lists the {\word tools} that are applicable to {\datatype strings}.
The following rules apply to {\datatype strings} and {\datatype string}
operations:
\beginlist
%% 18.0.0 7
\itemitem{--}
{\datatype Strings} may have {\word fill pointers}.
%% 18.0.0 4
\itemitem{--}
An {\word operator}
that uses the print name of an argument provided as a
{\datatype symbol} (most of
the operators in Figure {\chapno--\the\capno})
is not allowed to modify that {\datatype
symbol}.
%% 18.0.0 5
%% paragraph duplicated in descriptions of string-equal and string=
%% 18.0.0 6
%% paragraph duplicated in description of stringp
\endlist
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt char }&{\tt schar }&{\tt string= }\cr
{\tt string-equal }&{\tt string< }&{\tt string> }\cr
{\tt string<= }&{\tt string>= }&{\tt string/= }\cr
{\tt string-lessp }&{\tt string-greaterp }&{\tt string-not-greaterp }\cr
{\tt string-not-lessp }&{\tt string-not-equal }&{\tt make-string }\cr
{\tt string-trim }&{\tt string-left-trim }&{\tt string-right-trim }\cr
{\tt string-upcase }&{\tt string-downcase }&{\tt string-capitalize }\cr
{\tt nstring-upcase }&{\tt nstring-downcase }&{\tt nstring-capitalize }\cr
{\tt string }& & \cr
\noalign{\vskip -9pt} }}
\caption{String tools}
\endfig
\beginsubsubsection{\datatype Simple-string}
An {\word object} of type {\datatype simple-string}
(a {\datatype simple-string}) is
a {\datatype string} that is not displaced to another {\datatype string},
has no {\word fill pointer}, and is not to have its size adjusted
dynamically after
creation.
%% 2.4.0 2
%% 2.4.0 7
\beginsubsubsection{\datatype List}
The type {\datatype list} is
composed of {\word subtypes}
{\datatype cons} and {\datatype null}, which form an
{\word exhaustive partition}
of {\datatype list}.
An {\word object} of type {\datatype list}
(a {\datatype list})
is a chain of {\datatype conses}
linked by their {\word cdr} components
and terminated by @nil, the empty {\datatype list}.
The {\word car} components of the {\datatype conses}
are called the elements of the {\datatype list}.
For each element of the {\datatype list}
there is a {\datatype cons}. The empty {\datatype list}
has no elements at all.
A {\word dotted list}
is a chain of {\datatype conses}
linked by their {\word cdr} components
and not terminated by @nil.
Unless otherwise specified in this
standard, it is an error to pass a {\word dotted
list} to a {\word function}
that is specified to require a {\datatype list} as an argument.
The following figures contain lists of {\word tools} that are applicable to {\datatype
lists}.
Figure {\chapno--\the\capno} lists the {\datatype cons}
and {\datatype list} operation {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt car }&{\tt cdr }&{\tt caar }\cr
{\tt cadr }&{\tt cdar }&{\tt cddr }\cr
{\tt caaar }&{\tt caadr }&{\tt cadar }\cr
{\tt caddr }&{\tt cdaar }&{\tt cdadr }\cr
{\tt cddar }&{\tt cdddr }&{\tt caaaar }\cr
{\tt caaadr }&{\tt caadar }&{\tt caaddr }\cr
{\tt cadaar }&{\tt cadadr }&{\tt caddar }\cr
{\tt cadddr }&{\tt cdaaar }&{\tt cdaadr }\cr
{\tt cdadar }&{\tt cdaddr }&{\tt cddaar }\cr
{\tt cddadr }&{\tt cdddar }&{\tt cddddr }\cr
{\tt cons }&{\tt tree-equal }&{\tt endp }\cr
{\tt list-length }&{\tt nth }&{\tt first }\cr
{\tt second }&{\tt third }&{\tt fourth }\cr
{\tt fifth }&{\tt sixth }&{\tt seventh }\cr
{\tt eighth }&{\tt ninth }&{\tt tenth }\cr
{\tt rest }&{\tt nthcdr }&{\tt last }\cr
{\tt list }&{\tt list* } & {\tt make-list }\cr
{\tt append } & {\tt copy-list }&{\tt copy-alist }\cr
{\tt copy-tree }& {\tt revappend }&{\tt nconc }\cr
{\tt nreconc }& {\tt push }&{\tt pushnew }\cr
{\tt pop }& {\tt butlast }&{\tt nbutlast }\cr
{\tt ldiff } & &\cr
\noalign{\vskip -9pt} }}
\caption{List tools - 1}
\endfig
Figure {\chapno--\the\capno} lists the
{\datatype list} structure alteration and expression substitution {\word
tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt rplaca }&{\tt rplacd }&{\tt subst }\cr
{\tt subst-if }&{\tt subst-if-not }&{\tt nsubst }\cr
{\tt nsubst-if }&{\tt nsubst-if-not }&{\tt sublis }\cr
{\tt nsublis }& & \cr
\noalign{\vskip -9pt} }}
\caption{List tools - 2}
\endfig
Figure {\chapno--\the\capno} lists the set
operation and association list {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt member }&{\tt member-if } & {\tt member-if-not }\cr
{\tt tailp }&{\tt adjoin }& {\tt union }\cr
{\tt nunion }&{\tt intersection }& {\tt nintersection }\cr
{\tt set-difference }&{\tt nset-difference }& {\tt set-exclusive-or }\cr
{\tt nset-exclusive-or }&{\tt subsetp }& {\tt acons }\cr
{\tt pairlis }&{\tt assoc }& {\tt assoc-if }\cr
{\tt assoc-if-not }&{\tt rassoc }& {\tt rassoc-if }\cr
{\tt rassoc-if-not }&&\cr
\noalign{\vskip -9pt} }}
\caption{List tools - 3}
\endfig
\goodbreak
Following are examples of printed representations of {\datatype lists}:
\screen!
(a . b) ;A dotted pair of a and b
(a.b) ;A list of one element, the symbol named a.b
(a. b) ;A list of two elements a. and b
(a .b) ;A list of two elements a and .b
(a b . c) ;A dotted list of a and b with c at the end; two conses
.iot ;The symbol whose name is .iot
(. b) ;Illegal -- an error is signalled if an attempt is made to read
;this syntax.
(a .) ;Illegal -- an error is signalled.
(a .. b) ;Illegal -- an error is signalled.
(a . . b) ;Illegal -- an error is signalled.
(a b c ...);Illegal -- an error is signalled.
(a @bsl\ . b) ;A list of three elements a, ., and b
(a @vert\ .@vert b) ;A list of three elements a, ., and b
(a @bsl\ ... b) ;A list of three elements a, ..., and b
(a @vert\ ...@vert b) ;A list of three elements a, ..., and b
\endscreen!
∂02-Mar-89 0731 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Cryptography textbook
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Mar 89 07:31:22 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA05766; Thu, 2 Mar 89 07:29:05 -0800
Message-Id: <8903021529.AA05766@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Thu, 2 Mar 89 07:29:25 PST
Received: by BYUADMIN (Mailer R2.01A) id 6990; Thu, 02 Mar 89 08:28:20 MST
Date: Thu, 2 Mar 89 08:31:54 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
beigel@CS.JHU.EDU
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: beigel@CS.JHU.EDU
Subject: Cryptography textbook
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Can anyone recommend a textbook for a senior/1st-year-grad level
course on cryptography?
-- Richard Beigel
∂02-Mar-89 0834 X3J13-mailer Section 2.2 - part 4
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 2 Mar 89 08:33:46 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA02028; Thu, 2 Mar 89 08:31:42 PST
Message-Id: <8903021631.AA02028@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA02028; Thu, 2 Mar 89 08:31:42 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 2 Mar 89 07:40
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 2.2 - part 4
%%Types - part 4
\beginsubsubsection{\datatype Cons}
An {\word object} of type {\datatype cons}
is called a {\word cons}.
%% 2.5.0 1
\beginsubsubsection{\datatype Array\/}
The type {\datatype array\/} has {\word subtypes} {\datatype vector}
and {\datatype simple-array}.
An {\word object} of type {\datatype array\/}
(an {\datatype array\/})
contains {\word objects} arranged according
to a Cartesian coordinate system.
%% 17.0.0 3
The following rules apply to {\datatype arrays\/}.
\beginlist
\itemitem{--} An {\datatype array\/} contains components arranged according
to a rectilinear coordinate system.
%% 17.0.0 4
An {\datatype array\/}
may be a general {\datatype array\/}, meaning each element may be any @xlisp\
{\word object}, or it may be a specialized {\datatype array\/},
meaning that each element
must be of a restricted {\word type}.
%% 2.5.0 3
%% 2.5.0 4
\itemitem{--}
In principle, an
{\datatype array\/} in @clisp\ may have any number of dimensions, including zero.
It is permissible for a dimension to be zero, in which case
the {\datatype array\/}
has no elements, and any attempt to access an element
is an error. However, other properties of the {\datatype array\/},
such as the
dimensions themselves, may be used.
If the rank is zero, then there are no dimensions, and the
product of the dimensions is then by definition 1.
A zero-rank {\datatype array\/} therefore has a single element.
\itemitem{--} An implementation of may impose a limit on the rank of an
{\datatype array\/},
but this limit may not be smaller than 7.
The value of @conref[array-rank-limit] is the implementation's limit on
{\datatype array\/} rank.
\itemitem{--}Each dimension is a non-negative
{\datatype integer}; if any dimension of an {\datatype array\/} is zero,
the {\datatype array\/} has no elements.
%% 17.0.0 5
\itemitem{--}
General {\datatype vectors} may contain
any @xlisp\ {\word object}. {\datatype Vectors}
whose elements are restricted to type
{\datatype string-char} are called {\datatype strings}.
{\datatype Vectors} whose elements are
restricted to type {\datatype bit} are called {\datatype bit-vectors}.
%% 17.5.0 4
\itemitem{--}
Only {\datatype vectors} may have {\word fill pointers};
multidimensional {\datatype arrays\/} may not.
A multidimensional {\datatype array\/}
that is displaced to a {\datatype vector} that has
a {\word fill pointer} can be created.
%% 2.5.0 8
\itemitem{--}
Multidimensional {\datatype arrays\/}
store their components in row-major order;
that is, internally a multidimensional {\datatype array\/}
is stored as a one-dimensional
{\datatype array\/},
with the multidimensional index sets ordered lexicographically,
last index varying fastest.
%% 2.5.0 5
\itemitem{--}
An {\datatype array\/} element is specified by a series of indices.
The length of the series must equal the rank of the {\datatype array\/}.
Each index must be a non-negative {\datatype integer} strictly less than
the corresponding {\datatype array\/} dimension. {\datatype Array\/}
indexing is zero-origin.
\itemitem{--}
%% 17.1.0 13
When an array A is given as
the @Kwd[displaced-to] argument to {\function make-array}
when creating array B,
then array B is said to be displaced to array A. The
total number of elements in an {\datatype array\/},
called the total size of the {\datatype array\/},
is calculated as the product of all the dimensions.
It is required that the total size of A be no smaller than the sum
of the total size of B plus the offset @f[n] supplied by
the @Kwd[displaced-index-offset]
argument. The effect of displacing is that array B does not have any
elements of its own, but instead maps accesses to itself into
accesses to array A. The mapping treats both {\datatype arrays\/} as if they
were one-dimensional by taking the elements in row-major order,
and then maps an access to element @f[k] of array B to an access to element
@f[k]+@f[n] of array A.
\itemitem{--}
When {\keyword displaced-to} is supplied to {\function make-array},
{\keyword displaced-index-offset} is made to be the
index offset of the \array.
If {\keyword displaced-index-offset} is not supplied,
the index offset is zero.
\endlist
The following figures contain lists of {\word tools} that are applicable to {\datatype
arrays}.
Figure {\chapno--\the\capno} lists the {\datatype array\/}
creation, access, and information {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt make-array }&{\tt array-rank-limit }&{\tt array-dimension-limit }\cr
{\tt array-total-size-limit }&{\tt vector }&{\tt aref }\cr
{\tt svref }&{\tt array-element-type }&{\tt array-rank }\cr
{\tt array-dimension }&{\tt array-dimensions }&{\tt array-total-size }\cr
{\tt array-in-bounds-p }&{\tt array-row-major-index }&{\tt adjustable-array-p }\cr
{\tt upgraded-array-element-type} & {\tt upgraded-complex-part-type} & \cr
\noalign{\vskip -9pt} }}
\caption{Array tools - 1}
\endfig
Figure {\chapno--\the\capno} lists the {\word tools}
for operations on {\datatype arrays} of bits.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt bit }&{\tt sbit }&{\tt bit-and }\cr
{\tt bit-ior }&{\tt bit-xor }&{\tt bit-eqv }\cr
{\tt bit-nand }&{\tt bit-nor }&{\tt bit-andc1 }\cr
{\tt bit-andc2 }&{\tt bit-orc1 }&{\tt bit-orc2 }\cr
{\tt bit-not }&&\cr
\noalign{\vskip -9pt} }}
\caption{Array tools - 2}
\endfig
Figure {\chapno--\the\capno} lists
the {\datatype array\/} {\word fill pointer}
and dimension modification {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt array-has-fill-pointer-p }&{\tt fill-pointer }&{\tt vector-push}\cr
{\tt vector-push-extend }&{\tt vector-pop }&{\tt adjust-array }\cr
\noalign{\vskip -9pt} }}
\caption{Array tools - 3}
\endfig
%% 2.5.0 9
\beginsubsubsection{\datatype Simple-array}
The type {\datatype simple-array\/}
has {\word subtypes} {\datatype
simple-vector}, {\datatype simple-string}, and {\datatype simple-bit-vector}.
An {\word object} of type {\datatype simple-array\/}
(a {\datatype simple-array\/}) is
an {\datatype array\/}
that is not displaced to another {\datatype array\/},
has no {\word fill pointer}, and
is not to have its size adjusted dynamically after
creation.
%% 2.5.1 4
Implementations may provide certain specialized representations of
{\datatype arrays\/}
for efficiency in the case where all the components are of
the same specialized type.
All implementations are required to provide specialized {\datatype arrays\/}
of bits, that is, {\datatype objects} of type {\tt (array bit)};
the one-dimensional instances of
this specialization are called {\datatype bit-vectors}.
All implementations
provide specialized {\datatype arrays\/}
for the cases when the components
are {\datatype characters} (or rather,
a special subset of the {\datatype characters});
the one-dimensional instances of
this specialization are called {\datatype strings}.
%% 2.10.0 1
\beginsubsubsection{\datatype Stream}
An {\word object} of type {\datatype stream} (a {\datatype stream})
is a source or sink of data.
%% 21.0.0 3
%% 21.0.0 4
For example, character {\datatype streams}
produce or absorb {\datatype characters};
binary {\datatype streams} produce or absorb {\datatype integers}.
%% 21.0.0 3
A {\datatype stream}, whether a character stream or a binary
stream, may be input-only, output-only, or bidirectional.
What operations may be performed on a {\datatype stream} depends on which
type of {\datatype stream} it is.
%% 22.0.0 3
%All input/output operations are performed on {\datatype streams}
%of various kinds.
The following figures contain lists of {\word tools} that are applicable to {\datatype
streams}.
Figure {\chapno--\the\capno} lists the standard {\datatype streams}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
@var[standard-input] & @var[standard-output] & @var[error-output] \cr
@var[query-io] & @var[debug-io] & @var[terminal-io] \cr
@var[trace-output] & &\cr
\noalign{\vskip -9pt} }}
\caption{Stream tools - 1}
\endfig
Figure {\chapno--\the\capno} lists the {\datatype stream}
creation and manipulation {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt make-synonym-stream }&{\tt make-broadcast-stream }\cr
{\tt make-concatenated-stream} & {\tt make-two-way-stream }\cr
{\tt make-echo-stream }&{\tt make-string-input-stream }\cr
{\tt make-string-output-stream }&{\tt get-output-stream-string }\cr
{\tt with-open-stream } & {\tt with-input-from-string }\cr
{\tt with-output-to-string }& {\tt streamp } \cr
{\tt input-stream-p }&{\tt output-stream-p }\cr
{\tt stream-element-type } & {\tt close } \cr
\noalign{\vskip -9pt} }}
\caption{Stream tools - 2}
\endfig
\beginsubsubsection{\datatype Hash-table}
An {\word object} of type {\datatype hash-table} (a {\datatype hash-table})
contains keys and values.
%% 16.0.0 3
A {\datatype hash-table} maps a given
@xlisp\ {\word object} to another @xlisp\ {\word object} via a hash
mechanism.
Each {\datatype hash-table}
has a set of entries, each of which associates a
key with a value.
Figure {\chapno--\the\capno} lists the
{\word tools} that are applicable to {\datatype hash-tables}.
The following rules apply to {\datatype hash-tables}.
%% 16.0.0 4
\beginlist
\itemitem{--}
A {\datatype hash-table} can only associate one value with a given
key. Adding a value to a {\datatype hash-table} is a destructive operation;
the {\datatype hash-table} is modified.
%% 16.0.0 5
\itemitem{--}
There are three kinds of {\datatype hash-tables} -- those whose keys
are compared with {\function eq}, those whose keys
are compared with {\function eql}, and those whose keys
are compared with {\function equal}.
%% 16.0.0 6
\itemitem{--}
{\datatype Hash-tables} are created by
{\function make-hash-table}.
{\function gethash} is used to look up a key and find
the associated value.
New entries are added
to {\datatype hash-tables} using @Macref[setf] with {\function gethash}.
{\function remhash} is used to remove an entry.
For example:
@Lisp
(setq a (make-hash-table)) @EV #<Hash Table...>
(setf (gethash 'color a) 'brown) @EV BROWN
(setf (gethash 'name a) 'fred) @EV FRED
(gethash 'color a) @EV BROWN T
(gethash 'name a) @EV FRED T
(gethash 'pointy a) @EV @false @false
@Endlisp
%% 16.0.0 7
In this example, the {\word symbols} @f[color] and @f[name] are being used as
keys, and the {\word symbols} @f[brown] and @f[fred] are being used as the
associated values. The {\datatype hash-table}
has two items in it, one of which
associates from @f[color] to @f[brown]\rm, and the other of which
associates from @f[name] to @f[fred]\rm.
%% 16.0.0 8
\itemitem{--}
A key or a value may be any {\word object}.
%% 16.0.0 9
\itemitem{--}
When a {\datatype hash-table}
is first created, it has a size, which is the
maximum number of entries it can hold. Usually the actual capacity of
the table is somewhat less, since the hashing is not perfectly
collision-free. If so many entries are
added that the capacity is exceeded, the {\datatype hash-table}
will automatically
grow, and the entries will be rehashed (new hash values will be
recomputed, and everything will be rearranged so that the fast hash
lookup still works). This is transparent to the caller; it all happens
automatically.
%% 16.0.0 10
\itemitem{--}
The cases
of @f[nil] as a value and no entry in the {\datatype hash-table}
can be distinguished by the second value returned by {\function gethash}.
\endlist
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt make-hash-table }&{\tt hash-table-p }&{\tt gethash }\cr
{\tt remhash }&{\tt maphash }&{\tt clrhash }\cr
{\tt hash-table-count }&{\tt sxhash }&\cr
\noalign{\vskip -9pt} }}
\caption{Hash-table tools}
\endfig
%% 2.7.0 1
%% 22.1.5 2
\beginsubsubsection{\datatype Readtable}
An {\word object} of type {\datatype readtable} (a {\datatype readtable})
maps {\datatype
characters\/} into syntax
types for the {\word Lisp reader} (see ``Character Reader'').
A {\datatype readtable}
contains a macro
definition for
each {\datatype character} with macro character syntax.
Figure {\chapno--\the\capno} lists the
{\word tools} that are applicable to {\datatype readtables}.
See ``Object Syntax''.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
@var[readtable] & {\tt copy-readtable} \cr
{\tt readtablep } & {\tt set-syntax-from-char }\cr
{\tt set-macro-character }&{\tt get-macro-character }\cr
{\tt make-dispatch-macro-character }&{\tt set-dispatch-macro-character }\cr
{\tt get-dispatch-macro-character} & \cr
\noalign{\vskip -9pt} }}
\caption{Readtable tools}
\endfig
∂02-Mar-89 0905 X3J13-mailer Section 2.2 - part 5
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 2 Mar 89 09:05:12 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA05377; Thu, 2 Mar 89 09:03:02 PST
Message-Id: <8903021703.AA05377@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA05377; Thu, 2 Mar 89 09:03:02 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 2 Mar 89 07:42
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Section 2.2 - part 5
%% 2.8.0 1
\beginsubsubsection{\datatype Package}
An {\word object} of type {\datatype package} (a {\datatype package})
is a namespace that holds collections
of {\datatype symbols\/}.
%% 10.0.0 7
%% 11.0.0 4
A {\datatype package} is a data structure
that establishes a mapping from print
names to {\datatype symbols}.
At any given time one
{\datatype package}
is current. The current {\datatype package} is
the one that is the
value of @var[package]\rm. It is possible to refer to
{\datatype symbols} in
{\datatype packages}
other than the current one through the use of
package qualifiers in the representation of the {\datatype symbol}.
%% 11.0.0 5
The mappings in a {\datatype package} are divided
into two classes, external and internal. The
{\datatype symbols} accessible via these different mappings are
called external and
internal {\datatype symbols}
of the {\datatype package}. Within a
{\datatype package},
a print name refers to one {\datatype symbol} or to none; if it does refer
to a {\datatype symbol}, then it is either external or internal in that
{\datatype package}, but not both.
%% 11.0.0 6
External {\datatype symbols} are part of the package's public interface to other
{\datatype packages}.
{\datatype Symbols} become external
if they appear in {\function export}.
%% 11.0.0 7
A {\datatype symbol}
will always have the same
print name no matter what {\datatype package}
it appears in, but it may be external in some {\datatype
packages}
and internal in others.
A {\datatype symbol}
will not necessarily always have the same
printed representation because of the presence of package qualifiers ({\tt
:} and {\tt ::}).
%% 11.0.0 9
{\datatype Packages}
may be built up in layers. From the point of view of a
{\datatype package's} user,
the {\datatype package} is a single collection of mappings from
{\datatype strings} into internal and external {\datatype symbols}.
However, some of these
mappings may be established within the package itself, while other
mappings are inherited from other packages via {\function use-package}.
A {\datatype symbol} is
accessible in a {\datatype package} if it can be referred to
without a package qualifier when that {\datatype package} is current,
regardless of whether the mapping occurs within
that {\datatype package}
or via inheritance. A {\datatype symbol} is
present in a {\datatype package}
if the mapping is in the {\datatype package} itself and is
not inherited from somewhere else.
%% 5.1.2 6
%% 11.3.0 5
The {\datatype package}
named @f[keyword] contains all keyword {\datatype symbols}
used by the
@clisp\ system and by user-written code. Such {\datatype symbols} must be
easily accessible from any {\datatype package};
name conflicts are not an issue
because these {\datatype symbols\/}
are used only as labels, not to carry package-specific
attributes.
When a {\datatype symbol} is added to the @f[keyword] package, it
is made external, declared to be a constant, and is
made to
have itself as its value.
%% 11.0.0 19
Each {\datatype package} has a name (a {\datatype string})
and perhaps some nicknames. These
are assigned when the {\datatype package} is created
and can be changed
later.
%% 11.0.0 20
There is a single namespace for {\datatype packages}.
The function @Funref[find-package] translates a package
name or nickname into the
associated {\datatype package}.
The function @Funref[package-name] returns the name of a
{\datatype package}.
The function @Funref[package-nicknames] returns a {\datatype list} of all
nicknames for a {\datatype package}.
@Funref[rename-package] removes a
{\datatype package's}
current name and nicknames and replaces them with new ones
specified by the caller.
%% 11.0.0 35
{\datatype Symbols} from one {\datatype package}
may be made accessible in another {\datatype package} in
two ways.
%% 11.0.0 36
\beginlist
\itemitem{--}
Any individual {\datatype symbol}
may be added to a {\datatype package} by use
of @Funref[import]\rm. After the call to
{\function import}
it is possible to refer to the {\datatype symbols}
in the importing package
without any qualifier. The status of the {\datatype symbol}
in the {\datatype package}
it came from
is unchanged, and home package
for
this {\datatype symbol } is unchanged.
Once imported, a {\datatype symbol} is present in the
importing package
and can be removed only by calling {\function unintern}.
%% 11.4.0 4
A {\datatype symbol} is shadowed by another {\datatype symbol} in
some {\datatype package}
if the first {\datatype symbol} would be accessible by inheritance
if not for the presence of the second {\datatype symbol}.
The function @Funref[shadowing-import] causes the first {\datatype symbol}
to be imported without error
even if the second {\datatype symbol} is accessible.
%% 11.4.0 39
%% 11.4.0 40
\itemitem{--}
The second mechanism for making symbols from one package accessible in another
is provided by @Funref[use-package]\rm.
The function {\function unuse-package}
undoes the effects of a previous {\function use-package}.
\endlist
%% 11.4.0
There is no way to inherit the internal {\datatype symbols}
of another {\datatype package};
to refer to an internal {\datatype symbol},
the {\datatype symbol's} home
package must be made current,
a qualifier must be used, or the {\datatype symbol}
must be imported into the current
{\datatype package}.
%% 11.4.0 8
When a {\datatype symbol} is to be located in a
given {\datatype package}
the following occurs:
\beginlist
\itemitem{--} The {\datatype symbol} is looked for among the external and
internal {\datatype symbols} of the
{\datatype package} itself.
\itemitem{--} The
external {\datatype symbols} of the used {\datatype packages} are looked through
in some unspecified order. The
order does not matter; see the rules for handling name
conflicts listed below.
\endlist
%% 11.0.0 46
Within one {\datatype package}
any particular print name can refer to at most
one {\datatype symbol}. A name conflict
is said to occur when there is more than one candidate {\datatype symbol}.
Any time
a name conflict is about to occur,
a continuable error is signalled.
The following rules apply to name conflicts:
%% 11.0.0 47
\beginlist
%% 11.0.0 49
\itemitem{--}
Name conflicts are detected when they become possible, that is, when the
package structure is altered. Name
conflicts are not checked for during every name lookup.
\itemitem{--}
If the same {\datatype symbol}
is accessible to a {\datatype package} through more than
one path, there is no name conflict.
The same identical {\datatype symbol} cannot conflict with itself.
Name conflicts occur only between distinct {\datatype symbols} with
the same print name.
%% 11.0.0 48
\itemitem{--} Every {\datatype package} has a
list of shadowing {\datatype symbols}.
A shadowing {\datatype symbol} takes precedence over any
other {\datatype symbol} of the same print name
that would otherwise be accessible in the
{\datatype package}.
A name conflict involving a shadowing symbol is always
resolved in favor of the shadowing {\datatype symbol},
without signalling an error
(except for one exception involving {\function import}).
See @Funref[shadow] and @Funref[shadowing-import]\rm.
%% 11.0.0 50
\itemitem{--}
The functions {\function use-package}, {\function import}, and {\function export}
check for name
conflicts.
%% 11.0.0 52
\itemitem{--}
{\function shadow} and {\function shadowing-import}
never signal a name-conflict error.
%% 11.0.0 53
\itemitem{--}
{\function unuse-package}, {\function unexport}, and {\function unintern}
(when the {\datatype symbol}
being
uninterned is not a shadowing symbol) do not need to do any
name-conflict checking.
%% 11.0.0 54
\itemitem{--}
Giving a shadowing symbol to {\function unintern}
can uncover a name conflict that had
previously been resolved by the shadowing.
%% 11.0.0 55
\itemitem{--}
Aborting from a name-conflict error leaves the original {\datatype symbol}
accessible.
\itemitem{--}
Package functions signal name-conflict errors before making any
change to the package structure. When multiple changes are to be made,
it is
permissible for the implementation to process each change separately,
so that aborting from a name
conflict caused by the second {\datatype symbol}
in the {\datatype list} will not unexport the
first {\datatype symbol} in the {\datatype list}.
Multiple changes could be made with {\function export}.
%% 11.0.0 56
\itemitem{--}
Continuing from a name-conflict error should offer the user a chance to
resolve the name conflict in favor of either of the candidates. The
{\datatype package}
structure should be altered to reflect the resolution of the
name conflict, via {\function shadowing-import},
{\function unintern}, or {\function unexport}.
%% 11.0.0 57
\itemitem{--}
A name conflict in {\function use-package}
between a {\datatype symbol} directly present in the
using {\datatype package}
and an external {\datatype symbol} of the used
{\datatype package} is resolved
in favor of the first {\datatype symbol}
by making it a shadowing {\datatype symbol}, or in favor
of the second {\datatype symbol}
by uninterning the first {\datatype symbol} from the using
{\datatype package}.
%% 11.0.0 60
\itemitem{--}
A name conflict in {\function export} or {\function unintern}
due to a {\datatype package's}
inheriting two distinct {\datatype symbols}
with the same print name from two other
{\datatype packages}
may be resolved in favor of either {\datatype symbol} by importing it into
the using {\datatype package}
and making it a shadowing symbol, just as with
{\function use-package}.
\endlist
%% 11.2.0 5
Figure {\chapno--\the\capno}
lists the {\word tools} that are applicable
to {\datatype packages}.
For the {\word operators} listed here, all optional arguments named
{\arg package} default to the current value of @var[package]\rm. Where an
{\word operator}
takes an argument that is either a {\datatype symbol} or a {\datatype list}
of {\datatype symbols},
an argument of @false\ is treated as an empty {\datatype list} of
{\datatype symbols}. Any {\arg package}
argument may be either a {\datatype string}, a {\datatype symbol}, or
a {\datatype package}.
If a {\datatype symbol}
is supplied, its print name will be used as the {\datatype package}
name.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
@var[package] & {\tt make-package} & {\tt in-package} \cr
{\tt find-package }&{\tt package-name }&{\tt package-nicknames }\cr
{\tt rename-package }&{\tt package-use-list }&{\tt package-used-by-list }\cr
{\tt package-shadowing-symbols }&{\tt list-all-packages }&{\tt intern }\cr
{\tt find-symbol }&{\tt unintern }&{\tt export }\cr
{\tt unexport }&{\tt import }&{\tt shadowing-import }\cr
{\tt shadow }&{\tt use-package }&{\tt unuse-package }\cr
{\tt find-all-symbols }&{\tt do-symbols }&{\tt do-external-symbols }\cr
{\tt do-all-symbols }&{\tt modules }&{\tt provide }\cr
{\tt require }& & \cr
\noalign{\vskip -9pt}
}}
\caption{Package tools}
\endfig
%% 11.6.0 1
The following packages, at least, are built into every @clisp\ system:
%% 11.6.0 2
\beginlist
\itemitem{\tt lisp}
%% clean-up issue `contains all and only'
The package named @f[lisp] contains the primitives of the
@clisp\ system. Its external symbols include all of the
user-visible functions and global variables that are present in the
@clisp\ system, such as {\function car}, {\function cdr}, @var[package]\rm, etc.
%% 11.6.0 3
\itemitem{\tt user}
%% clean-up issue `lisp package and may use other packages as well'
The @f[user] package is the value of @var[package] when
a @clisp\ system starts up. This package uses the @f[lisp] package.
%% 11.6.0 4
\itemitem{\tt keyword}
This package contains all of the keywords used by built-in
or user-defined @xlisp\ functions. Printed symbol representations
that start with a colon are interpreted as referring to symbols
in this package, which are always external symbols. All symbols in this
package are treated as constants that evaluate to themselves.
The function {\function symbol-value} may be used to retrieve these values.
%% 11.6.0 5
\itemitem{\tt system}
This package name is reserved to the implementation,
uses the @f[lisp] package, and has the
nickname @f[sys]\rm.
\endlist
\beginsubsubsection{\datatype Pathname}
%% 23.1.1 1
All file systems dealt with by @clisp\ are forced into a common framework
in which files are named by an object of type {\datatype pathname},
a {\datatype pathname},
that can be translated by the underlying operating system to a file
name.
%% 23.1.1 3
A {\datatype pathname} always has six components, described below.
These components
are the common interface that allows programs to work the same way with
different file systems; the mapping of the pathname components into the
concepts peculiar to each file system is
implementation-dependent.
%% 23.1.1 4
\beginlist
%% 23.1.1 5
%% 23.1.1 17
\itemitem{\bf Host}
The name of the file system on which the file resides.
The host may be a
{\datatype string}, indicating a file system, or a
{\datatype list}
of {\datatype strings},
of which the first names the file system and the rest
may be used for inter-network routing.
\itemitem{\bf Device}
Corresponds to the ``device'' or ``file structure'' concept in many
host file systems: the name of a (logical or physical) device containing files.
%% 23.1.1 6
\itemitem{\bf Directory}
Corresponds to the ``directory'' concept in many host file systems:
the name of a group of related files.
%% 23.1.1 7
\itemitem{\bf Name}
The name of a group of files that can be thought of as
conceptually the ``same'' file.
%% 23.1.1 8
%% 23.1.1 15
\itemitem{\bf Type}
Corresponds to the ``filetype'' or ``extension'' concept in many host
file systems. This says what kind of file this is.
The type is always a {\datatype string}, @nil\ or {\keyword :wild}.
When the type is not supplied, its value is implementation-dependent.
%% 23.1.1 9
%% 23.1.1 16
\itemitem{\bf Version}
Corresponds to the ``version number'' concept in many host file systems.
The version is either a positive {\datatype integer}
or a {\datatype symbol } from the following list:
{\function nil}, {\keyword :wild}, or
{\keyword :newest} (refers to the largest version number
that already exists in the file system when reading a file, or to
a version number
greater than any already existing in the file system
when writing a new file). Implementations
may define other special version {\datatype symbols}.
\endlist
The following rules apply to the components of a {\datatype pathname}.
%% 23.1.1 12
\beginlist
\itemitem{--}
Not all of the components of a {\datatype pathname}
need to be supplied. If a
component of a {\datatype pathname}
is missing, its value is @nil\rm. Before the file
system interface can do anything with a file, such as opening the
file, all the missing components of a {\datatype pathname} must be filled in
from a set of defaults.
Parsing a namestring
that does not contain certain components will result in a
{\datatype pathname} with
missing components.
%% 23.1.1 13
\itemitem{--}
A component of a {\datatype pathname} can also be the keyword {\keyword
:wild},
which means that the {\datatype pathname}
component matches anything.
%% 23.1.1 14
\itemitem{--}
Except where otherwise specified, the values
for components of a {\datatype pathname} are
implementation-dependent.
%% 23.1.1 18
\itemitem{--}
The device, directory, and name components can each be a {\datatype string}
(with
implementation-dependent rules on allowed characters and length) or possibly
some other @clisp\ {\word object}
which has an implementation-dependent format.
Supplying a {\datatype string}
as a pathname component for a host that requires an {\word object} as a
component will cause conversion of the {\datatype string} to the appropriate
{\word object}.
\endlist
%% 23.1.1 10
A {\datatype pathname}
is not necessarily the name of a specific file.
Rather, it is a specification (possibly only a partial specification) of
how to access a file.
A {\datatype pathname}
need not correspond to any file that
actually exists, and more than one {\datatype pathname}
can refer to the same file.
For example, the {\datatype pathname}
with a version of {\keyword :newest} may refer to the
same file as a {\datatype pathname}
with the same components except a certain number
as the version. Indeed, a {\datatype pathname}
with version {\keyword :newest} may refer to
different files as time passes, because the meaning of such a {\datatype
pathname}
depends on the state of the file system.
%% 23.1.1 11
{\datatype Pathnames} that are specified by {\datatype strings}
(called namestrings) are parsed and
merged. Parsing is the conversion of a namestring
into a {\datatype pathname}. This operation is
implementation-dependent, because the format of namestrings
is implementation-dependent.
Merging takes a {\datatype pathname} with missing components
and supplies values for those components from a source of defaults.
%% 23.1.1 20
An implementation is free to accommodate other file system features in its
{\datatype pathname} representation and provide a parser that can process such
specifications in namestrings. A program that
depends explicitly on any such features will not be portable.
The following figures contain lists of {\word tools} that are applicable to the
file system interface.
Figure {\chapno--\the\capno} lists the {\datatype pathname} {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt pathname }&{\tt truename }&{\tt parse-namestring }\cr
{\tt merge-pathnames }& @var[default-pathname-defaults]&{\tt make-pathname }\cr
{\tt pathnamep }&{\tt pathname-host }&{\tt pathname-device }\cr
{\tt pathname-directory }&{\tt pathname-name }&{\tt pathname-type }\cr
{\tt pathname-version }&{\tt namestring }&{\tt file-namestring }\cr
{\tt directory-namestring }&{\tt host-namestring }&{\tt enough-namestring }\cr
{\tt user-homedir-pathname } & & \cr
\noalign{\vskip -9pt} }}
\caption{File System Interface tools - 1}
\endfig
Figure {\chapno--\the\capno} lists the file and directory {\word tools}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt directory} &{\tt open }&{\tt with-open-file }\cr
{\tt rename-file }&{\tt delete-file }&{\tt probe-file }\cr
{\tt file-write-date }&{\tt file-author }&{\tt file-position }\cr
{\tt file-length} & {\tt load} & @var[load-verbose] \cr
\noalign{\vskip -9pt} }}
\caption{File System Interface tools - 2}
\endfig
%% 2.11.0 1
\beginsubsubsection{\datatype Random-state}
An {\word object} of type {\datatype random-state} (a {\datatype random-state}
object)
contains state information used by the pseudo-random number generator.
%% 12.9.0 1
The pseudo-random numbers
in a random number series are implementation-dependent,
but the distribution of the numbers should
be machine-independent.
Figure {\chapno--\the\capno} lists
the {\word tools} that are applicable to {\datatype random-state}.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt random} & @var[random-state] & \cr
{\tt make-random-state} & {\tt random-state-p} & \cr
\noalign{\vskip -9pt}
}}
\caption{Random-state tools}
\endfig
\issue{FUNCTION-TYPE:X3J13-MARCH-88}
\beginsubsubsection{\datatype Function}
An {\word object} of type {\datatype function\/} is called a {\datatype
function}.
A {\datatype function}
may be supplied as an argument without error to @Funref[funcall]
or @Funref[apply]\rm, and is
to be executed as code when arguments are supplied.
The functional computation produces one or more values, produces no
values, or
takes a non-local exit.
The type {\datatype function} has at least one {\word subtype} called
{\datatype compiled-function}.
Implementations are free to define other {\word subtypes} of
the type {\datatype function}.
\beginsubsubsection{\datatype Compiled-function}
An object of type {\datatype compiled-function} is a called a {\datatype
compiled-function}.
%% 2.13.0 2
A {\datatype compiled-function} is a compiled code {\word object}
that has been produced by the
compiler.
\endissue{FUNCTION-TYPE:X3J13-MARCH-88}
\beginsubsubsection{\datatype Nil}
The empty data type, which contains no {\word objects}, is
denoted by @nil\rm.
\beginsubsubsection{\datatype Common}
The type {\datatype common} encompasses all the
{\word objects} required by the @clisp\ language. An implementation
is free to provide other
{\word types} that are not {\word subtypes} of the type {\datatype common}.
\endsubSection%{Data Type Definition}
%% Type Specifiers
\beginsubSection{Type Specifiers}
\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
The following will be deleted:
%% 4.5.0 5
Type specifiers are used for two different purposes:
declaration and discrimination.
\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
There are two reasons that an {\word object}'s type is used:
\beginlist
\itemitem{1.} The consequences are undefined if an
{\word object} is an argument to an {\word operator}
and the argument
is not one of the {\word operator}'s required {\word types}.
\itemitem{2.} If run-time optimizations in compiled code are desired,
it is often necessary to reduce the number of {\word types} of {\word objects}
a variable can hold.
\endlist
%% 4.1.0 1
The type specifiers (they are {\datatype symbols})
defined by the system are those shown in Figure
{\chapno--\the\capno}.
%% 4.3.0 4
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt array}&{\tt integer}&{\tt short-float}\cr
{\tt atom}&{\tt keyword}&{\tt signed-byte}\cr
{\tt bignum}&{\tt list}&{\tt simple-array}\cr
{\tt bit}&{\tt long-float}&{\tt simple-bit-vector}\cr
{\tt bit-vector}&{\tt mod}&{\tt simple-string}\cr
{\tt character}&{\tt nil}&{\tt simple-vector}\cr
{\tt common}&{\tt null}&{\tt single-float}\cr
{\tt compiled-function}&{\tt number}&{\tt standard-char}\cr
{\tt complex}&{\tt package}&{\tt stream}\cr
{\tt cons}&{\tt pathname}&{\tt string}\cr
{\tt double-float}&{\tt random-state}&{\tt string-char}\cr
{\tt fixnum}&{\tt ratio}&{\tt symbol}\cr
{\tt float}&{\tt rational}&{\tt t}\cr
{\tt function}&{\tt readtable}&{\tt unsigned-byte}\cr
{\tt hash-table}&{\tt sequence}&{\tt vector}\cr
\noalign{\vskip -9pt} }}
\caption{Table of Atomic Type Specifiers}
\endfig
The syntax for type specifiers is illustrated in Figure {\chapno--\the\capno}.
\boxfig
{\advance\baselineskip by 2.5pt
\halign{\hskip\leftskip\hfil#&#\hfil\cr
{\it typespec\/}::$=\;$&{\it atomic-type-specifier\/}\cr
$\vert\;$& \paren {{\tt satisfies} predicate-name\/}\cr
$\vert\;$& \paren {{\tt member} \star{\curly{object}}}\cr
$\vert\;$& \paren {{\tt not} typespec\/}\cr
$\vert\;$& \paren {{\tt and} \star{\curly{typespec}}}\cr
$\vert\;$& \paren {{\tt or} \star{\curly{typespec}}}\cr
$\vert\;$& \paren {{\tt array} {\ttbrac{\curly{typespec $\vert$ {\tt *} } \brac{dimensions}}}}\cr
$\vert\;$& \paren {{\tt simple-array} {\ttbrac{\curly{typespec $\vert$ {\tt *} } \brac{dimensions}}}}\cr
$\vert\;$& \paren {{\tt vector} {\ttbrac{\curly{typespec $\vert$ {\tt *} } \brac{\curly{size $\vert$ {\tt *}}}}}}\cr
$\vert\;$& \paren {{\tt simple-vector} \ttbrac{\it size\/}}\cr
$\vert\;$& \paren {{\tt string} \ttbrac{\it size\/ $\vert$ {\tt *}}}\cr
$\vert\;$& \paren {{\tt simple-string} \ttbrac{\it size\/ $\vert$ {\tt *}}}\cr
$\vert\;$& \paren {{\tt bit-vector} \ttbrac{\it size\/ $\vert$ {\tt *}}}\cr
$\vert\;$& \paren {{\tt simple-bit-vector} \ttbrac{\it size\/ $\vert$ {\tt *}}}\cr
$\vert\;$& \paren {{\tt integer} \ttbrac{integer-limit \brac{integer-limit}}}\cr
$\vert\;$& \paren {{\tt fixnum} \ttbrac{fixnum-limit \brac{fixnum-limit}}}\cr
$\vert\;$& \paren {{\tt mod} \ttbrac{\it integer\/ $\vert$ {\tt *}}}\cr
$\vert\;$& \paren {{\tt signed-byte} \ttbrac{\it size\/ $\vert$ {\tt *}}}\cr
$\vert\;$& \paren {{\tt unsigned-byte} \ttbrac{\it size\/ $\vert$ {\tt *}}}\cr
$\vert\;$& \paren {{\tt rational} \ttbrac{rational-limit \brac{rational-limit}}}\cr
$\vert\;$& \paren {{\tt float} \ttbrac{float-limit \brac{float-limit}}}\cr
$\vert\;$& \paren {{\tt short-float} \ttbrac{short-float-limit \brac{short-float-limit}}}\cr
$\vert\;$& \paren {{\tt single-float} \ttbrac{single-float-limit \brac{single-float-limit}}}\cr
$\vert\;$& \paren {{\tt double-float} \ttbrac{double-float-limit \brac{double-float-limit}}}\cr
$\vert\;$& \paren {{\tt long-float} \ttbrac{long-float-limit \brac{long-float-limit}}}\cr
$\vert\;$& \paren {{\tt complex} \ttbrac{typespec $\vert$ {\tt *}}}\cr
$\vert\;$& \paren {{\tt function} \ttbrac{arg-typespec-list \brac{value-typespec}}}\cr
}}
\caption{Syntax for Type Specifiers}
\endfig
Figure {\chapno--\the\capno} gives the definitions
applicable to the syntax for type specifiers.
\boxfig
{\advance\baselineskip by 2.5pt
\halign{#\hfil&#\hfil\cr
{\it arg-typespec-list\/}::$=$ \vtop{\hbox{\star{(\curly{typespec}}
\ttbrac{{\opt} {\star{\curly{typespec\/}}}}
\ttbrac{{\rest} {\it typespec\/}}
\hbox{\quad\ttbrac{{\key{}} \star{\curly{\it typespec\/}}}{\rm )}}}} & \cr
{\it value-typespec\/}::$=$ {\it typespec\/} $\vert$ \paren{{\tt values} . {\it arg-typespec-list\/}} & \cr
{\it dimensions\/}::$=$ {\it integer\/} $\vert$ {\tt *} $\vert$
\paren{\star{\curly{integer $\vert$ {\tt *} }}} & \cr
{\it size\/}::$=$ {\it integer\/} & \cr
{\it integer-limit\/}::$=$ {\it integer\/} $\vert$ {\tt *}
$\vert$ ({\it integer\/}) & \cr
{\it fixnum-limit\/}::$=$ {\it fixnum\/} $\vert$ {\tt *}
$\vert$ ({\it fixnum\/}) &\cr
{\it rational-limit\/}::$=$ {\it rational\/} $\vert$ {\tt *} $\vert$ ({\it rational\/})\cr
{\it float-limit\/}::$=$ {\it float\/} $\vert$ {\tt *} $\vert$ ({\it float\/})\cr
{\it short-float-limit\/}::$=$ {\it short-float\/} $\vert$ {\tt *} $\vert$ ({\it short-float\/})\cr
{\it single-float-limit\/}::$=$ {\it single-float\/} $\vert$ {\tt *} $\vert$ ({\it single-float\/})\cr
{\it double-float-limit\/}::$=$ {\it double-float\/} $\vert$ {\tt *} $\vert$ ({\it double-float\/})\cr
{\it long-float-limit\/}::$=$ {\it long-float\/} $\vert$ {\tt *} $\vert$ ({\it long-float\/})\cr
}}
\caption{Definitions for Syntax for Type Specifiers}
\endfig
%% 4.2.0 1
If a type specifier is a {\datatype list}, the {\word car}
of the {\datatype list}
is a {\datatype symbol}, and the rest of the {\datatype list}
is subsidiary
{\word type} information. The subsidiary items may be
unspecified. The unspecified subsidiary items are indicated
by writing @f[*]\rm. For example, to completely specify
a {\datatype vector}, the {\word type} of the elements
and the length of the {\datatype vector}, must be present.
@lisp
(vector double-float 100)
@endlisp
To leave the length unspecified:
@lisp
(vector double-float *)
@endlisp
To leave the element type unspecified:
@lisp
(vector * 100)
@endlisp
Suppose that two type specifiers are the same except that the first
has a @f[*] where the second has a more explicit specification.
Then the second denotes a {\word subtype}
of the {\word type} denoted by the first.
%% 4.2.0 2
If a {\datatype list}
has one or more unspecified items at the end, those items
may be dropped.
If dropping all occurrences of @f[*] results in a singleton {\datatype list},
then the parentheses may be dropped as well (the list may be replaced
by the {\datatype symbol} in its {\word car}).
For example,
{\tt (vector double-float *)}
may be abbreviated to {\tt (vector double-float)},
and {\tt (vector * *)} may be abbreviated to {\tt (vector)}
and then to
{\tt vector}.
A list of possible type specifier {\datatype lists} follows:
\beginlist
%% 4.3.0 1
\itemitem
{\tt (satisfies {\arg predicate-name})}
This denotes
the set of all {\word objects}
that satisfy the predicate {\arg predicate-name},
which must be a {\datatype symbol}
whose global {\word function} definition is a one-argument
predicate.
A name is required for {\arg predicate-name}; {\word lambda-expressions}
are not allowed.
For example, the type {\tt (satisfies numberp)} is the
same as the type {\datatype number}.
The call {\tt (typep x '(satisfies p))}
results in applying @f[p] to @f[x]
and returning @f[t] if the result is true and @nil\ if the result is false.
%% 4.3.0 2
For example, the type {\datatype string-char} could be defined as
@lisp
(deftype string-char () '(and character (satisfies string-char-p)))
@endlisp
%% 4.4.0 3
\itemitem
{\tt (member {\arg object1} {\arg object2} ...)}
This denotes the set
containing the named {\arg objects}. An {\word object} is of
this {\word type}
if and only if it is @Funref[eql] to one of the specified {\arg objects}.
%% 4.4.0 4
\itemitem
{\tt (not {\arg type})}
This denotes the set of all {\word objects} that
are not of the type {\arg type}.
%% 4.4.0 5
\itemitem{\tt (and {\arg type1} {\arg type2} ...)}
This denotes the set of all {\word objects} of the
{\word type} determined by the intersection of
{\arg type1}, {\arg type2},....
%% 4.4.0 7
\itemitem{\tt (or {\arg type1} {\arg type2} ...)}
This denotes the set of all {\word objects} of the
{\word type} determined the union of {\arg type1}, {\arg type2},....
For example, the type {\datatype list}
by definition is the same as
{\tt (or null cons)}. Also, the value
returned by
@Funref[position] is of type {\tt (or null (integer 0 *))}
(either @nil\ or a non-negative {\datatype integer}).
%% 4.6.0 3
\itemitem{\tt (integer {\arg low} {\arg high})}
This denotes the {\datatype integers} between
{\arg low} and {\arg high}. {\arg Low} and {\arg high}
must each be {\datatype integers}, a {\datatype list}
of an {\datatype integer}, or unspecified.
An {\datatype integer} is an inclusive limit,
a {\datatype list} of an {\datatype integer} is an exclusive limit, and
@f[*] means that a limit does not exist
and so effectively denotes minus or plus infinity, respectively.
{\datatype Fixnum} is a name
for {\tt (integer {\arg smallest} {\arg largest})}
for implementation-dependent
values of {\arg smallest} and {\arg largest}.
The type {\tt (integer 0 1)}
has the name {\datatype bit}.
%% 4.6.0 4
\itemitem{\tt (mod {\arg n})}
This denotes the set of non-negative {\datatype integers} less than {\arg
n}.
This is equivalent to {\tt (integer 0 {\it n}-1)}
or to {\tt (integer 0 ({\it n}))}.
%% 4.6.0 5
\itemitem{\tt (signed-byte {\arg s})}
This denotes the set of {\datatype integers} that can be represented
in two's-complement form in a byte of {\arg s} bits. This is
equivalent to
{\tt (integer $-2↑{s-1} 2↑{s-1}-$1)}.
The type {\datatype signed-byte} or the type {\tt (signed-byte *)}
is the same as the type {\datatype integer}.
%% 4.6.0 6
\itemitem{\tt (unsigned-byte {\arg s})}
This denotes the set of non-negative {\datatype integers} that can be
represented in a byte of {\arg s} bits. This is equivalent to
{\tt (mod $2↑s$)},
that is, {\tt (integer 0 $2↑s-$1)}.
The type {\datatype unsigned-byte} or
the type {\tt (unsigned-byte *)} is the same as
the type {\tt (integer 0 *)}, the set of non-negative {\datatype integers}.
%% 4.6.0 7
\itemitem{\tt (rational {\arg low} {\arg high})}
This denotes the {\datatype rationals} between
{\arg low} and {\arg high}. {\arg Low} and {\arg high}
must each be a {\datatype rational}, a {\datatype list} of a {\datatype
rational}, or unspecified.
A {\datatype rational} is an inclusive limit,
a {\datatype list} of a {\datatype rational} is an exclusive limit, and
@f[*] means that a limit does not exist
and so denotes minus and plus infinity, respectively.
%% 4.6.0 8
%% 4.6.0 9
\itemitem{\tt (float {\arg low} {\arg high})}
\itemitem{\tt (short-float {\arg low} {\arg high})}
\itemitem{\tt (single-float {\arg low} {\arg high})}
\itemitem{\tt (double-float {\arg low} {\arg high})}
\itemitem{\tt (long-float {\arg low} {\arg high})}
These denote the set of {\datatype floating}-point numbers between
{\arg low} and {\arg high}. {\arg Low} and {\arg high}
must each be a {\datatype floating}-point number,
a {\datatype list} of a {\datatype floating}-point number,
or unspecified. A {\datatype floating}-point number
is an inclusive limit, a {\datatype list} of a
{\datatype floating}-point number is an exclusive limit, and
@f[*] means that a limit does not exist
and so denotes minus and plus infinity, respectively.
In the case of the types {\tt short-float}, {\tt single-float},
{\tt double-float}, or {\tt long-float},
if a limit is a {\datatype floating}-point
number (or a {\datatype list} of one),
it must be one of the appropriate format.
%% 4.6.0 10
\itemitem{\tt (string {\arg size})}
This denotes the same type as
the type {\tt (array string-char ({\arg size}))}:
the set of {\datatype strings} of size {\arg size}.
%% 4.6.0 11
\itemitem{\tt (simple-string size {\arg size})}
This denotes the same type
as the type {\tt (simple-array string-char ({\arg size}))}: the set of
{\datatype simple-strings} of size {\arg size}.
%% 4.6.0 12
\itemitem{\tt (bit-vector {\arg size})}
This denotes the same type as the type {\tt (array bit ({\arg size}))}:
the set of {\datatype bit-vectors} of size {\arg size}.
%% 4.6.0 13
\itemitem{\tt (simple-bit-vector {\arg size})}
This denotes the same type as the type
{\tt (simple-array bit ({\arg size}))}: the set of
{\datatype simple-bit-vectors} of size {\arg size}.
%% 4.5.0 6
%% 4.5.0 7
\itemitem{\tt (array {\arg element-type dimensions})}
This denotes the set
of {\datatype arrays\/}
whose elements are all of type {\arg element-type}
and whose dimensions are {\arg dimensions}.
{\arg Element-type} must be a valid type specifier or unsupplied.
{\arg Dimensions} must be a non-negative {\datatype integer},
which is the number
of dimensions, or a {\datatype list} of non-negative {\datatype integers}
representing the length of each dimension (any dimension
may be unsupplied instead), or it may be unsupplied.
\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
The following will be left out:
For declaration purposes, this {\word type} encompasses those
{\datatype arrays\/}
that can result by supplying {\arg element-type} as the element type
to the function @Funref[make-array]\rm; this may be different
from what the {\word type} means for discrimination purposes.
For example:
@lisp
(array integer 3) ;Three-dimensional arrays of integers
(array integer (* * *)) ;Three-dimensional arrays of integers
(array * (4 5 6)) ;4-by-5-by-6 arrays
(array character (3 *)) ;Two-dimensional arrays of characters that have
;three rows
(array short-float @empty) ;Zero-rank arrays of short-floats
@Endlisp
\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
{\tt (array *)} refers to all {\datatype arrays\/}
regardless of element type, {\tt (array {\arg type-specifier})}
refers only to those {\datatype arrays\/}
that can result from giving {\arg type-specifier} as the
{\tt :element-type} argument to {\function make-array}.
\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
Note that the type {\tt (array t)}
is a subset of the type {\tt (array *)}.
The reason is that the type {\tt (array t)} is the set of {\datatype arrays\/}
that can
hold any {\word object} (the elements are of type
{\datatype t},
which includes all {\word objects}).
On the other hand, the type {\tt (array *)}
is the set of all {\datatype arrays\/} whatsoever, including for example
{\datatype arrays\/} that can hold only {\datatype characters}.
Now
the type {\tt (array character)} is not a subset of the type {\tt (array t)};
the two sets
are {\word disjoint} because the type {\tt (array character)} is not the
set of all {\datatype arrays\/} that can hold
{\datatype characters}, but rather the set of
{\datatype arrays\/}
that are specialized to hold precisely {\datatype characters} and no
other {\word objects}.
\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
The following will be deleted:
The following expression cannot be used to determine if
array @f[foo] can hold a {\datatype character}:
@lisp
(typep foo '(array character))
@endlisp
The following expression can be used to determine if
array @f[foo] can hold a {\datatype character}:
@lisp
(subtypep 'character (array-element-type foo))
@endlisp
\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
%% 4.5.0 8
\itemitem{\tt (simple-array {\arg element-type dimensions})}
This is equivalent
to the type {\tt (array {\arg element-type} {\arg dimensions})}
except that it additionally
specifies that the {\datatype array\/}
{\word objects} are {\datatype simple-arrays}.
\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
{\tt (simple-array *)} refers to all {\datatype simple-arrays\/}
regardless of element type, {\tt (simple-array {\arg type-specifier})}
refers only to those {\datatype simple-arrays\/}
that can result from giving {\arg type-specifier} as the
{\tt :element-type} argument to {\function make-array}.
\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
%% 4.5.0 9
\itemitem{\tt (vector {\arg element-type} {\arg size})}
This denotes the set of specialized
one-dimensional {\datatype arrays\/}
whose elements are all of type {\arg element-type}
and whose lengths are size {\arg size}. This is equivalent to
the type {\tt (array {\arg element-type} ({\arg size}))}.
For example:
@lisp
(vector double-float) ;Vectors of double-format floating-point numbers
(vector * 5) ;Vectors of length 5
(vector t 5) ;General vectors of length 5
(vector (mod 32) *) ;Vectors of integers between 0 and 31
@Endlisp
The types {\tt (vector string-char)} and {\tt (vector bit)}
have the names {\datatype string} and {\datatype bit-vector}.
Every implementation of @clisp\ must provide distinct representations for
these as distinct specialized {\word types}.
\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
{\tt (vector *)} refers to all {\datatype vectors\/}
regardless of element type, {\tt (vector {\arg type-specifier})}
refers only to those {\datatype vectors\/}
that can result from giving {\arg type-specifier} as the
{\tt :element-type} argument to {\function make-array}.
\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
%% 4.5.0 10
\itemitem{\tt (simple-vector {\arg size})}
This is the same
as the type {\tt (vector t {\arg
size})} except that it additionally specifies
that its elements are {\datatype simple-vectors}.
%% 4.5.0 11
\itemitem{\tt (complex {\arg type})}
Every element of this {\word type} is a
{\datatype complex\/} number whose real part
and imaginary part are each of type {\arg type}.
This {\word type} encompasses those
{\datatype complex\/} numbers
that can result by giving numbers of the specified {\word type}
to @Funref[complex]\rm.
\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
The following will be deleted:
This may be different
from what the {\word type} means for discrimination purposes.
For example, Gaussian integers might be
described as the type {\tt (complex integer)}, even in implementations
where giving two {\datatype integers} to {\function complex\/} results
in an {\word object} of type {\tt (complex rational)}.
\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
%% 2.1.4 3
The type of a specific {\datatype complex\/} number is indicated by a list
of the word @f[complex] and the type of the components; for example,
a specialized representation for {\datatype complex\/}
numbers with {\datatype short-float}
parts would be of type {\tt (complex short-float)}. The type
{\datatype complex\/}
encompasses all complex representations.
\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
{\tt (typep {\arg object} '(complex {\arg type-specifier}))}
refers to all {\datatype complex\/} numbers that can result from
giving {\datatype numbers} of type {\arg type-specifier}
to the function {\function complex\/}, plus all other
{\datatype complex\/} numbers
of the same specialized representation.
Both the real and the imaginary parts of any such
{\datatype complex\/} number must
satisfy:
{\tt (typep {\arg realpart}|{\arg imagpart} '{\arg type-specifier})}
\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
%% 4.5.0 12
\itemitem{\tt (function ({\arg arg1-type} {\arg arg2-type} ...)
{\arg value-type})}
\issue{FUNCTION-TYPE}
The list form of the type {\datatype function}
may be used only for declaration and not for discrimination.
\endissue{FUNCTION-TYPE}
Every element of this {\word type} is
a {\word function} that accepts arguments at least of the
types
specified by the {\arg argj-type} forms and returns a value that is a
member of the types specified by the {\arg value-type} form. The
@optional, @rest, @key,
\issue{FUNCTION-TYPE-KEY-NAME}
and @allowotherkeys\
\endissue{FUNCTION-TYPE-KEY-NAME}
markers may appear in the list of argument
types.
\issue{FUNCTION-TYPE-KEY-NAME}
The @key\ parameters
should be supplied as lists of the form {\tt (keyword type)}.
The {\tt keyword} must
be a valid keyword-name
symbol and must be supplied in the actual arguments of a
call. This is usually a {\datatype symbol} in the {\tt keyword} package
but can be any {\datatype symbol}.
The @allowotherkeys\ declarations are interpreted as follows:
when @key\ is given in a
{\tt function} type specifier lambda list,
it is safe to assume that the @key s given
are exhaustive unless @allowotherkeys\ is present.
@allowotherkeys\ is an indication
that other keyword arguments may actually be
supplied and, if supplied, may be used.
For example,
the type of the function {\function make-list} could be declared as:
@lisp
(function make-list ((integer 0) &key (:initial-element t)) list)
@endlisp
\endissue{FUNCTION-TYPE-KEY-NAME}
The {\arg value-type} may be a {\tt values}
type specifier in order to indicate the
{\word types} of multiple values.
%% 4.5.0 13
For example, the function @Funref[cons] is of type
{\tt (function (t t) cons)},
because it can accept any two arguments and always returns a {\word
cons}.
{\function cons} is
also of type {\tt (function (float string) list)},
because it can
accept a {\datatype floating}-point number
and a {\datatype string} (among other things), and its
result is always of type {\datatype list}
(in fact a {\word cons} is never {\datatype null},
but that does not matter for this type declaration).
@Funref[truncate] is of type
{\tt (function (number number) (values number number))},
as well as of type
{\tt (function (integer (mod 8)) integer)}.
%% 4.5.0 14
\itemitem{\tt (values {\arg value1-type} {\arg value2-type} ...)}
This type specifier may be used only
as the {\arg value-type} in a {\tt function} type specifier or in
@Specref[the]\rm. It is used to specify individual {\word types} when
multiple values are involved.
The
@optional, @rest, and @key\ markers may appear in the {\arg value-type} list;
they indicate the parameter list of a
{\word function} that,
when given to @Specref[multiple-value-call] along with
the values, would be suitable for receiving those values.
\endlist
%% 4.7.0 1
New type specifiers can come into existence in two ways.
\beginlist
\itemitem{\bull} Defining a structure or class
with @Macref[defstruct] or {\function defclass} automatically
causes the name of the structure or class to be a new type specifier
{\datatype symbol}.
\itemitem{\bull} {\function deftype} can be used to define new type specifier
abbreviations.
\endlist
Figure {\chapno--\the\capno}
lists the {\word tools} that are applicable to types and declarations.
\boxfig
{\dimen0=.75pc
\tabskip \dimen0 plus .5 fil
\halign to \hsize {#\hfil\tabskip \dimen0 plus 1fil&#\hfil\tabskip \dimen0 plus
1fil&#\hfil\cr
\noalign{\vskip -9pt}
{\tt deftype }&{\tt coerce }&{\tt type-of }\cr
{\tt declare }&{\tt locally }&{\tt proclaim }\cr
{\tt the }&{\tt defstruct }&\cr
\noalign{\vskip -9pt} }}
\caption{Type and declaration tools}
\endfig
\beginsubsubsection{Type Upgrading}
\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
When type specifiers are used to declare {\word objects} to be of a certain
{\word type}, they are said to be used
for declaration. A type specifier used for declaration
can be the
{\tt :element-type} argument to
{\function make-array}, the {\arg result-type}
argument to {\function coerce},
an argument to the special form {\function the},
or an argument to {\function declare}.
An {\word object} declared to be of a certain
{\word type} may not satisfy
{\function typep} with that type specifier.
This is permissible because an implementation
is required only to construct the
result out of the most specialized {\word type} that can
accommodate elements of the {\word type} supplied as the argument
to the {\tt :element-type} named argument to {\function make-array}.
That is, an implementation may only provide a
very small number of {\word types} for storing
{\datatype arrays\/},
and it is permitted to upgrade any {\word type} request into
one of its built-in repertoire.
One type specifier with
this property is {\tt (array {\arg type-specifier})}
for various implementation-dependent values of {\arg type-specifier}.
Another type specifier with this property is
{\tt (complex {\arg type-specifier})}.
{\word Type} upgrading implies a movement upwards in the type
hierarchy lattice. In the case of {\datatype arrays\/}
the {\arg type-specifier} must be
a {\word subtype} of
{\tt (upgraded-array-element-type '{\arg type-specifier})}.
In the case of {\datatype complex\/} numbers, the
{\arg type-specifier} must be a {\word subtype} of
{\tt (upgraded-complex-part-type {\arg type-specifier})}.
If {\arg type-specifier1} is a {\word subtype} of {\arg type-specifier2}, then
{\tt (upgraded-array-element-type '{\arg type-specifier1})}
must also be a {\word subtype} of
{\tt (upgraded-array-element-type '{\arg type-specifier2})}.
Two {\word disjoint types} can be upgraded into
the same thing.
See {\function array-element-type}.
Upgrading an {\datatype array\/} element {\word type} is independent of any
other property of {\datatype arrays\/},
such as {\word rank}, adjustability, {\word fill-pointers}, or
displacement.
The reason {\word rank} is included is because
it would not be consistently possible to displace {\datatype arrays\/}
to those of
differing {\word rank} if {\word rank} were not included.
\endissue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING}
\endsubsubsection%{Type Upgrading}
\endsubSection%{Type Specifiers}
∂02-Mar-89 0928 X3J13-mailer forwarding note from gregor from larry
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 2 Mar 89 09:27:42 PST
Date: Wed, 01 Mar 89 13:15:48 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890301.131548.baggins@almvma>
Subject: forwarding note from gregor from larry
=========================================================================
Received: from Xerox.COM by ibm.COM on 02/23/89 at 10:00:35 PST
Received: from Semillon.ms by ArpaGateway.ms ; 23 FEB 89 09:56:23 PST
Date: Thu, 23 Feb 89 09:56 PST
From: Gregor.pa@Xerox.COM
Subject: [masinter.pa: Re: cs proposal straw vote]
To: baggins@IBM.com
Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest
Included-msgs: The message of 22 Feb 89 20:59 PST from masinter.pa
Included-References: The message of 22 Feb 89 12:08 PST from
baggins@IBM.com
Message-ID: <19890223175611.1.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no
Larry asked me to forward this to you as the official Xerox position on
the straw ballot.
Date: Wed, 22 Feb 89 20:59 PST
From: masinter.pa
My personal opinion:
CHAR-FONT-UNUSED-CHAR-BITS-NONPORTABLE:
Eliminate of font and bit attributes.
**** Yes
Add rules for an implementation supporting attributes.
**** No. Attributes can be done as
attributes of subclass of CHARACTER.
Remove any description of
implementation-supported attributes.
Remove CHAR-FONT-LIMIT
Remove CHAR-BITS-LIMIT
Remove INT-CHAR
Remove CHAR-BITS
Remove CHAR-FONT
Remove MAKE-CHAR
Remove CHAR-CONTROL-BIT
Remove CHAR-META-BIT
Remove CHAR-SUPER-BIT
Remove CHAR-HYPER-BIT
Remove CHAR-BIT
Remove SET-CHAR-BIT
**** Yes.
Issue: CHAR-INT-ONLY-USEFUL-WHEN-ATTRIBUTES-SUPPORTED
Proposal:
Remove CHAR-INT
**** YES
Issue: CHARACTER-TYPE-RESTRICTIVE
Define BASE-CHARACTER as a subtype of STRING.
Standard characters are a subset of the base
characters.
STANDARD-CHAR type is replaced by (CHARACTER :STANDARD)
Remove the semi-standard characters.
**** NO.
Define (CHARACTER :STANDARD) in the same
way that STANDARD-CHAR used to be.
Define BASE-CHARACTER as
(upgraded-array-element-type '(CHARACTER :STANDARD)).
Remove the semi-standard characters.
<<You might argue that this has the same effect, but
it doesn't.>>
Issue: STRING-TYPE-RESTRICTIVE
Proposal:
Define STRING as a union type
*** YES
STRING used as a type specifier for object creation
means (VECTOR CHARACTER)
*** YES
All string functions operate as specified on any
string object except it is an error to insert
an extended character into a base string.
*** NO. It is an error to insert an object in an
array where the object is not of the element type
of the array.
<<You might argue this has the same effect, but
my wording here is more general.>>
Extend the COERCE function to allow coercion from
base string to extended string.
*** NO. This is unnecesarry. COERCE already
coerces from one vector type to another.
Issue: STRING-TYPE-ABBREVIATIONS
Proposal:
Add BASE-STRING
Add GENERAL-STRING
*** NO. Unnecessary, confusing, clutter.
Issue: SIMPLE-STRING-TYPE-RESTRICTIVE
Proposal:
Define SIMPLE-STRING as a union type
Define SIMPLE-STRING as a type specifier for object
creation means (SIMPLE-ARRAY CHARACTER (size))
*** NO. Confusing. Poor performance model.
SIMPLE isn't simple.
Issue: SIMPLE-STRING-TYPE-ABBREVIATIONS
Proposal:
Add SIMPLE-BASE-STRING
Add SIMPLE-GENERAL-STRING
*** NO, even if SIMPLE-STRING-TYPE-RESTRICTIVE adopted.
Unnecessary. Useless clutter.
Issue: FILE-EXTERNAL-REPRESENTATION
Proposal:
Add :EXTERNAL-CODED-CHARACTER-FORMAT keyword to OPEN
*** NO, wrong name. Unspecified. Better to omit than to
add with unspecified or poorly specified behavior.
Better to add as "future direction" in standard than in current
state.
Issue: STRING-BINARY-WIDTH
Proposal:
Add :EXTERNAL-CODED-STRING-LENGTH function
*** NO, even if you meant to omit the :. CL currently doesn't
admit that text and binary can be intermixed. No standard
way to use information returned. No relation to
FILE-POSITION defined.
Issue: CHAR-CODE-NON-PORTABLE
Proposal:
Add CHAR-CCS-VALUE function
*** NO. Requires lots of implementation mechanism.
Of limited use in nearly all situations.
Issue: CHARACTER-IDENTIFICATION-NONPORTABLE
Proposal:
Introduce the concept of Registries
*** IF modified; should only suggest names of
character repertoires, and name at least
STANDARD HIRAGANA KATAKANA
GREEK. Standardization of repertoire elements
to be specified in future.
Standardize on #\registry:id
*** YES, as suggestion
add all-implemented-registries
*** NO
Add *ALL-CHARACTER-REGISTRY-NAMES* variable
*** NO
Add FIND-CHAR function
*** NO, NAME-CHAR will do
Add CHAR-LABEL function
*** NO, CHAR-NAME will do
Add CHAR-REGISTRY-NAME function
*** NO, string processing on CHAR-NAME will do
New syntax for CHARACTER type specifier
*** YES
New #\label:registry character name syntax
*** ??? This was already mentioned
New argument to CHARACTERP
*** YES.
-------
∂02-Mar-89 0928 X3J13-mailer forwarding mail from gray
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 2 Mar 89 09:28:08 PST
Date: Wed, 01 Mar 89 15:59:07 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890301.155907.baggins@almvma>
Subject: forwarding mail from gray
=========================================================================
Received: from dsg.csc.ti.com by ibm.COM on 03/01/89 at 10:29:25 PST
Received: from ti.com by RELAY.CS.NET id aa05395; 28 Feb 89 23:18 EST
Received: by ti.com id AA00500; Tue, 28 Feb 89 22:18:18 CST
Received: from Kelvin by tilde id AA21544; Tue, 28 Feb 89 22:08:43 CST
Message-Id: <2813717283-5615057@Kelvin>
Sender: GRAY%kelvin.csc.ti.com@RELAY.CS.NET
Date: Tue, 28 Feb 89 22:08:03 CST
From: David N Gray <Gray%dsg.csc.ti.com@RELAY.CS.NET>
To: Thom Linden <baggins@IBM.COM>
Cc: CL-Characters@SAIL.STANFORD.EDU, Bartley%mips.csc.ti.com@RELAY.CS.NET,
Waldrum%tilde.csc.ti.com@RELAY.CS.NET
Subject: Re: cs proposal straw vote
In-Reply-To: Msg of Wed, 22 Feb 89 12:08:15 PST from Thom Linden <baggins@IBM.com>
> I would like to take a straw vote on various components of
> the Characters proposal. The primary intent is to resolve the
> actual list of items to be voted upon at the March meeting.
> Let me know if you think some items should be separated or
> combined
...
> Issue: CHAR-FONT-UNUSED-CHAR-BITS-NONPORTABLE
> Problem: CHAR-FONT isn't used, CHAR-BITS isn't portable.
> Proposal:
> Eliminate of font and bit attributes.
> Add rules for an implementation supporting attributes.
> Redefine STRING-CHAR as implementation defined.
> Remove CHAR-FONT-LIMIT
> Remove CHAR-BITS-LIMIT
> Remove INT-CHAR
> Remove CHAR-BITS
> Remove CHAR-FONT
> Remove MAKE-CHAR
> Remove CHAR-CONTROL-BIT
> Remove CHAR-META-BIT
> Remove CHAR-SUPER-BIT
> Remove CHAR-HYPER-BIT
> Remove CHAR-BIT
> Remove SET-CHAR-BIT
Yes, I can accept this.
---
> Issue: CHAR-INT-ONLY-USEFUL-WHEN-ATTRIBUTES-SUPPORTED
> Problem: CHAR-INT behavior is CHAR-CODE unless implementation
> defined attributes are supported.
> Proposal:
> Remove CHAR-INT
I had to stop and think about why this wasn't part of the previous issue.
Perhaps the thought was that a portable way to turn all of a character into
a number (e.g. for a hash code) would be desirable even if only some
implementations support attributes? That sounds like a legitimate
concern, so I vote No.
--
> Issue: CHARACTER-TYPE-RESTRICTIVEC
> Problem: CHARACTER type doesn't allow thin & fat characters.
> Proposal: a
> Define BASE-CHARACTER as a subtype of STRING. a
> Standard characters are a subset of the base
> characters.
> STANDARD-CHAR type is replaced by (CHARACTER :STANDARD)
> Remove the semi-standard characters.
I have been unable to imagine the reason for linking semi-standard
characters with fat characters; these should be separate issues.
Yes to fat characters.
---
No to removing the semi-standard characters. I still have yet to hear a
-- plausible rationale for doing this.
> Issue: STRING-TYPE-RESTRICTIVE
> Problem: STRING type doesn't allow thin & fat strings.
> Proposal: a
> Define STRING as a union type a
> STRING used as a type specifier for object creation
> means (VECTOR CHARACTER)
> All string functions operate as specified on any a
> string object except it is an error to insert
> an extended character into a base string.
> Extend the COERCE function to allow coercion from a
> base string to extended string.
Yes.
---
> Issue: STRING-TYPE-ABBREVIATIONS
> Problem: new types are awkward to name, want abbreviations.
> Proposal: ne
> Add BASE-STRING
> Add GENERAL-STRING
Yes.
---
> Issue: SIMPLE-STRING-TYPE-RESTRICTIVE
> Problem: SIMPLE STRING type doesn't allow thin & fat strings.
> Proposal: a
> Define SIMPLE-STRING as a union type a
> Define SIMPLE-STRING as a type specifier for object
> creation means (SIMPLE-ARRAY CHARACTER (size))
Yes.
---
> Issue: SIMPLE-STRING-TYPE-ABBREVIATIONS
> Problem: new types are awkward to name, want abbreviations.
> Proposal: ne
> Add SIMPLE-BASE-STRING
> Add SIMPLE-GENERAL-STRING
Yes.
---
> Issue: FILE-EXTERNAL-REPRESENTATION
> Problem: can't specify external encoding even when there are lots
> Proposal:
> Add :EXTERNAL-CODED-CHARACTER-FORMAT keyword to OPEN
Yes.
---
> Issue: STRING-BINARY-WIDTH
> Problem: Can't find out how many bytes a string will take when written as
> text
> Proposal:
> Add :EXTERNAL-CODED-STRING-LENGTH function
No; I'm not sure that this has been adequately thought out.
--
> Issue: CHAR-CODE-NON-PORTABLE
> Problem: no way to talk about well-known external coding methods, only
> internal codes
> Proposal:
> Add CHAR-CCS-VALUE function
Yes, although I'm not too happy about the name; "value" doesn't really say
--- much. Why not CHAR-CCS-INDEX ? Or CHAR-EXTERNAL-CODE ? Yes also to
the inverse function.
> Issue: CHARACTER-IDENTIFICATION-NONPORTABLE
> Problem: Can't portably talk about non-standard characters
> Proposal:
> Introduce the concept of Registries
> Standardize on #\registry:id, add all-implemented-registries
> Add *ALL-CHARACTER-REGISTRY-NAMES* variable
> Add FIND-CHAR function
> Add CHAR-LABEL function
> Add CHAR-REGISTRY-NAME function
> New syntax for CHARACTER type specifier
> New #\label:registry character name syntax
> New argument to CHARACTERP
No. I'm not convinced that this approach is feasible or even necessary.
--- There appears to be a great deal of machinery being created solely to
support the premise stated in section 2.2 that all characters need to
be decomposable into one and only one name. I don't see the need for
that.
∂02-Mar-89 0930 X3J13-mailer cs proposal comments
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 2 Mar 89 09:30:00 PST
Date: Thu, 02 Mar 89 02:27:38 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890302.022738.baggins@almvma>
Subject: cs proposal comments
Just a reminder, please send comments/straw ballots to x3j13 and
not the characters mailing list.
Regards,
Thom
∂02-Mar-89 0929 X3J13-mailer cs proposal comments
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 2 Mar 89 09:29:33 PST
Date: Thu, 02 Mar 89 02:20:21 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890302.022021.baggins@almvma>
Subject: cs proposal comments
>> But if we decide that "my alpha" _is_ the same as "your alpha", then which
>> of our languages' registry gets to include it? I can see a lot of
>> confusion over characters that are used the same in more than one
>> language.
I don't see the confusion. German, English, Italian, etc. have a large
overlap of characters. One would expect these to all be in a single
registry, eg. Latin. Again, the important factor is that a character
is uniquely named. There is no advantage of one registry over another.
>>
>> I'm not so much concerned with who decides this as with whether this
>> approach is even feasible. The lack of even a "for example" scenario of
>> how this might work leaves me with a lot of doubts about whether it _can_
>> work. Also, it is not apparent why anyone outside the Common Lisp
>> community would have any interest in participating in such a standards
>> effort.
I believe other languages have the same problems as Lisp. For example,
COBOL has standardized names for coded character sets in
their I/O interface. In particular, SC22 wants to address the
international character handling issues across all (prog.)languages.
I'm attending an SC22 ad hoc committee meeting on characters next
week (and will let this forum know what interest I find).
>>
>>
>> Page 7 of the draft dated February 21 says that
>>
>> "The proposed ISO Character Registry Standard is fixed; an
>> implementation may not extend a standard registry's constituent
>> set of characters beyond the standard definition."
>>
>> That says to me that if an implementation is going to add a character,
>> then it can only be added to an implementation-defined registry. What
>> happens then if a new edition of the registry standard includes that
>> character in one of the standard registries? Since a character is not
>> permitted to be a member of more than one registry, that immediately
>> becomes an incompatible change for anyone who has been using that
>> character. Consequently, even extensions by standards revision will be
>> discouraged. That seems quite non-extensible to me.
Nothing prevents the implementation from providing a warning message
and behaving properly for some period of time. Users are encouraged
to use a 'new' standardized name since that name has a portable
meaning.
But, what the statement says to me is that if I use a name in the
standard registry, I have a guarentee that it does not have an
implementation unique meaning. Also, it is impossible for an
implementation to add character names which conflict with any
'new' standardized character.
>>
>>
>> So CHAR< etc. have no portable meaning unless both arguments are standard
>> characters in one of the partial ordering groups on page 237 of CLtL?
>> If you are going to have a Greek alphabet that is required to be disjoint
>> from the Latin alphabet anyway, wouldn't you want to know that the Greek
>> letters could be sorted in the expected order?
Well, I don't know the 'expected' order for Greek. In general, the
expected order is culturally dependent and using CHAR< as a sorting
mechanism is not sufficient. If we take the Latin registry
as including accented characters, there are different orderings
depending on whether you are in a Spanish, German, Danish, etc.
context. For Common Lisp to impose a single one is certainly
be wrong. In general, I don't think the ordering of individual
characters by CHAR< is as important as standardized definitions
of ordering strings for culturally expected results (such as, dictionary
ordering).
>>
>> > >> Page 25 section A.4.5 doesn't specify the syntax of a registry name; did
>> > >> you intend it to be a string?
>> >
>> > These have been changed to be symbols.
>>
>> Fine, but it appears that the new draft still doesn't say that.
>>
>> > >> Page 29 - *ALL-REGISTER-NAMES* -- a list of strings?
>> >
>> > Now a list of symbols.
>>
>> Again, the document doesn't say that.
p24,26,28,33: Right. I actually said they are 'names'. This may be
too general and can be changed to 'keyword symbols' without any
difficulty.
>>
>> That sounds good, but don't we also need the inverse function, to
>> construct a character object given a CCS and index?
>>
>> >
>> > That really depends on the definition of a conforming program. Is
>> > this defined yet?
>>
>> Never mind that; the real question is why do you want the standard to not
>> specify the meaning of tabs and form-feeds in source files?
>>
I don't have my CLtL with me but I don't think a meaning is given
to the semi-standard characters (unless we consider them self defining?)
>>
>> In the character table on page 17, do the "graphic labels" have any
>> significance? I don't see that the document uses them or requires them to
>> be used in any way. If not, that column should be deleted. I hope that
>> this is _not_ an example of what character names in a registry would look
>> like.
It is simply an assist in uniquely identifing each standard character
since glyphs can be ambigious.
>>
>> Your message of January 24 said you were going to:
>>
>> -- modify char-name, name-char, and #\name to accept character
>> names of the form 'registry:label'
>>
>> but I can't see that this draft does that. In particular, it is not at
>> all apparent how this is supposed to affect CHAR-NAME. Should I expect
>> (CHAR-NAME #\NEWLINE) to return "NEWLINE" or something like
>> "CONTROL:NEWLINE"? Are #\SPACE and #\NEWLINE to be the only characters
>> that can be referenced by a name that does not included a registry prefix?
>> Since all characters will have a label in some registry, does that mean
>> that CHAR-NAME will never return NIL anymore?
The form label:registry is given on p38 where for #\, "In particular,
an implementation may support names of the form label:registry."
It could do with repeating on p35 (name-char, char-name).
If a 'control' registry is standardized, I would expect these names
to replace (eventually) the various names now used. Some revision
of the Common Lisp standard might deprecate the current forms once
(if) a Character Registry standard is adopted.
∂02-Mar-89 1000 X3J13-mailer Re: cs proposal and straw vote
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 2 Mar 89 09:59:49 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA03605; Thu, 2 Mar 89 10:57:45 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA03241; Thu, 2 Mar 89 10:57:42 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903021757.AA03241@defun.utah.edu>
Date: Thu, 2 Mar 89 10:57:40 MST
Subject: Re: cs proposal and straw vote
To: baggins@ibm.com
Cc: x3j13@sail.stanford.edu
In-Reply-To: Dan L. Pierson <pierson@mist.encore.com>, Wed, 01 Mar 89 15:49:59 EST
I pretty much agree with the points Dan raised. I generally support
(with varying degrees of enthusiasm) all of the subissues except the
last one, dealing with character registries.
My major complaints at this point are:
- I also don't feel that I could vote for the document in its current
form. At the very least, there should be some kind of cross-reference
indicating which parts of the document correspond to which of the
subissues you've identified, so that we know exactly what language
we are voting on for each of them. And, I would still like to see
a rationale presented for each of the subissues.
- I really believe it would be premature to standardize on the idea of
character registries at this time. I don't think that the idea is
inherently bad and awful, but given that the specifics of the proposal
do not appear to have stabilized and nobody has implemented it yet, I
think we would be running an unacceptable risk of standardizing the
wrong thing.
A few other nits:
I'm confused about what happens to the STRING-CHAR type. There is a
definition for it on page 22 but on the bottom of page 23 it is
removed from the table of standard type specifiers. And, which
subissue would removing it fall under? It's not mentioned in any of
the ones you list.
On page 28, it says: "There may be unassigned codes between 0 and
char-code-limit which are not legal arguments to code-char." Don't
you really mean to say "... for which code-char returns NIL"?
Why do we need CHAR-CODE-LIMIT, CODE-CHAR, and CHAR-CODE anyway?
While bits and fonts were in the standard, these were useful for
things like creating a character with the same code but different bits
or font attributes, but now that's out. If we want a function to use
for hashing characters, that's what CHAR-INT is for. The only other
use I can think of is supporting iteration over characters, and it
seems like this could be extremely inefficient in implementations that
support user-defined character sets. (In such a case, I would imagine
that one would make CHAR-CODE-LIMIT correspond to the limit imposed by
the representation, perhaps the same as MOST-POSITIVE-FIXNUM, but in
actual practice, very few of those codes would have corresponding
characters.) I agree with Dan that we'd be better off having a
specialized iterator.
Should we consider extending MAKE-STRING-OUTPUT-STREAM to take an
:ELEMENT-TYPE keyword?
-Sandra
-------
∂02-Mar-89 1151 X3J13-mailer Re: cs proposal comments
Received: from ti.com by SAIL.Stanford.EDU with TCP; 2 Mar 89 11:51:39 PST
Received: by ti.com id AA08145; Thu, 2 Mar 89 13:50:34 CST
Received: from Kelvin by tilde id AA05068; Thu, 2 Mar 89 13:39:29 CST
Message-Id: <2813859524-5211323@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 2 Mar 89 13:38:44 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Thom Linden <baggins@IBM.com>
Cc: x3j13@sail.stanford.edu
Subject: Re: cs proposal comments
In-Reply-To: Msg of Thu, 02 Mar 89 02:20:21 PST from Thom Linden <baggins@IBM.com>
> >> Never mind that; the real question is why do you want the standard to not
> >> specify the meaning of tabs and form-feeds in source files?
> >>
> I don't have my CLtL with me but I don't think a meaning is given
> to the semi-standard characters (unless we consider them self defining?)
I'm talking about page 336 of CLtL which specifies that the reader treats
#\TAB and #\PAGE as whitespace. Section A.22.1.1 of the February 21 document
specifies deleting the mention of these.
> The form label:registry is given on p38 where for #\, "In particular,
> an implementation may support names of the form label:registry."
> It could do with repeating on p35 (name-char, char-name).
"_may_ support"? It seems like either this should be part of the standard or
not. What does CHAR-NAME return for non-standard characters if the
implementation doesn't support this? If you are going to permit referencing
names that way, then what do we need registries for? Also, the sentence
quoted is in the context of non-graphic characters. What about names for
non-standard graphic characters? Do standard graphic characters have names?
∂02-Mar-89 1421 emma@csli.Stanford.EDU CSLI Calendar, 2 March, 4:18
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Mar 89 14:21:33 PST
Received: by csli.Stanford.EDU (4.0/inc-1.0)
id AA17358; Thu, 2 Mar 89 13:43:21 PST
Date: Thu, 2 Mar 89 13:43:21 PST
From: emma@csli.Stanford.EDU (Emma Pease)
Message-Id: <8903022143.AA17358@csli.Stanford.EDU>
To: friends@csli.Stanford.EDU
Subject: CSLI Calendar, 2 March, 4:18
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
2 March 1989 Stanford Vol. 4, No. 18
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
SYMBOLIC SYSTEMS FORUM
A Computational Psychology Approach to Commonsense Perception
Jeffry Shrager
Friday, 3 March, 3:15
Room 60:61N
Commonsense Perception is a generalized version of what Dretske has
called "epistemic seeing"---that is, knowledge-based interpretation of
(perceptual) experience. In this talk I will outline a psychological
approach to the study of commonsense perception in incremental concept
learning. My goal is a computational framework and model whose basic
processing cycle is knowledge revision by commonsense perception, and
which subsumes rule-based inference, perceptual reasoning, and most
inductive and instructed learning tasks.
____________
LINGUISTICS DEPARTMENT COLLOQUIUM
Language Acquisition: "A Creolist's View"
Lawrence Carrington
University of the West Indies and Stanford
Friday, 3 March, 3:15
Cordura Conference Room
____________
CSLI SEMINAR
Indexicality and Quantified Modal Logic
Harry Deutsch
Illinois State University
Tuesday, 7 March, 4:00
Cordura Conference Room
Relations between recent philosophy of language and the semantics of
modality (possible worlds semantics) have not been good. I attempt to
mediate the dispute by formulating quantified modal logic (QML) so as
to incorporate some insights of the "new theory of reference" (NTR).
This sheds some new light on both QML and the NTR.
____________
SYMBOLIC SYSTEMS FORUM
Ontology and Computers
Ruben Kleiman
Apple Intelligent Agents Group
Friday, 10 March, 3:15
Room 60:61N
This talk will be about artificial intelligence and knowledge
representation, focusing on how to encode knowledge into a computer.
On one hand, Winograd, Flores, and Putnam have advocated a
phenomenological view that abandons the standard mentalist position.
On the other hand, there are also many people (Hayes, McCarthy,
Dennett, and most AI workers) who keep the mentalist position. Dr.
Kleiman will attempt to reconcile these two philosophical positions.
____________
LINGUISTICS DEPARTMENT COLLOQUIUM
A Union Analysis of Noun Incorporation
Donna Gerdts, SUNY at Buffalo
Friday, 10 March, 3:15
Cordura Conference Room
____________
∂02-Mar-89 1502 chandler@polya.Stanford.EDU Test
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Mar 89 15:02:47 PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA01473; Thu, 2 Mar 89 14:59:17 -0800
Date: Thu, 2 Mar 1989 14:58:18 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: retreat@polya.Stanford.EDU
Subject: Test
Message-Id: <CMM.0.87.604882698.chandler@polya.stanford.edu>
∂02-Mar-89 1510 chandler@polya.Stanford.EDU Another test
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Mar 89 15:10:21 PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA02098; Thu, 2 Mar 89 15:07:44 -0800
Date: Thu, 2 Mar 1989 15:07:06 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: retreat@polya.Stanford.EDU
Subject: Another test
Message-Id: <CMM.0.87.604883226.chandler@polya.stanford.edu>
∂02-Mar-89 1632 X3J13-mailer minor comments on the character proposal
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Mar 89 16:31:53 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 549744; Thu 2-Mar-89 19:29:32 EST
Date: Thu, 2 Mar 89 19:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: minor comments on the character proposal
To: Thom Linden <baggins@IBM.com>
cc: x3j13@SAIL.STANFORD.EDU
In-Reply-To: <890222.120815.baggins@almvma>
Message-ID: <19890303002938.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
These comments are not an official response to your request for a vote.
Here are some comments on the character proposal version of 21 Feb 89.
I believe these are all merely editorial, but if they are matters of
disagreement I'd like to know.
p.29, describing character attributes: It needs to be clarified that
these notes apply to all implementation-defined character attributes,
not just to attributes that might be provided for compatibility with
the earlier version of Common Lisp.
Some of these notes have not been consistently reflected elsewhere in
the proposal, for example, page 31 seems to say that the only difference
between char-equal and char-= involves alphabetic case, whereas page 29
says that char-= compares all attributes but char-equal compares an
implementation-defined set of attributes (page 29 is correct).
Similarly, where p.31 says "if the codes of two characters differ, then
they are different", it should instead say "if the codes or
implementation-defined attributes (if any) of two characters differ,
then they are different."
Two of the notes on p.29 refer to char-int and int-char, which you are
proposing to remove, so those notes should be removed.
p.33, 35: Under find-char, char-registry-name, and char-label you
indicate that registry names and labels are strings. In fact they
are symbols now, these places need to be updated.
p.38: Where it says "an implementation may support names of the
form label:registry", I believe this to be a typo for "registry:label".
The colon is evidently being used by analogy to packages, so the
registry name should precede the label, just as the package name
precedes the symbol name.
∂02-Mar-89 1729 @polya.Stanford.EDU:tah@linz MTC Seminar
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Mar 89 17:29:28 PST
Received: from linz.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA11953; Thu, 2 Mar 89 17:25:15 -0800
Received: by linz.stanford.edu (5.59/25-eef) id AA07593; Thu, 2 Mar 89 17:24:36 PDT
Message-Id: <8903030124.AA07593@linz.stanford.edu>
To: lop@polya
Subject: MTC Seminar
Reply-To: tah@cs.stanford.edu
Date: 02 Mar 89 17:24:33 PST (Thu)
From: Tom Henzinger <tah@linz>
There will be no MTC seminar tomorrow (March 3). -t
∂02-Mar-89 1819 @Score.Stanford.EDU:jle@Orange.stanford.edu CS Colloquium
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Mar 89 18:19:37 PST
Received: from Orange.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 2 Mar 89 18:10:13-PST
Received: by Orange.stanford.edu (5.59/25-eef) id AA04629; Thu, 2 Mar 89 18:10:07 PDT
Date: Thu, 2 Mar 89 18:10:07 PDT
From: Jeffrey Eppinger <jle@Orange.stanford.edu>
Message-Id: <8903030210.AA04629@Orange.stanford.edu>
To: csd-list@score
Subject: CS Colloquium
The next Computer Science Colloquium will be on March 14th:
The Computer Productivity Paradox
Michael L. Dertouzos
Professor and Director
MIT Laboratory for Computer Science
Computer Science Colloquium
Tuesday, March 14, 1989, 4:15pm
Jordan Hall (Building 420), Room 040
Stanford University
(Refreshments will be provided)
Abstract
The first half century of the computer field has been largely supply side
driven by a wondrous new technology that is still evolving and continues
to fuel our imagination. One side of the paradox lies in the apparent
lack of aggregate effect (either up or down) of computers on conventional
measures of human productivity. The other side of the paradox lies in the
indifference of makers and users of computer hardware and software about
the effect of such systems upon human productivity. The talk will examine
how computers might help current productivity weaknesses especially of the
white collar kind, how they might open new productive endeavors, how they
should not be misused and how information might be valued so that we can
develop effective measures of information-processing productivity. The
mission ahead is historic--to apply computer science and information
technology across the world's entire economic front so as to increase
human productivity. The associated question is equally ominous:
Can it be done?
∂02-Mar-89 1831 @Score.Stanford.EDU:jle@Orange.stanford.edu CS Colloquium
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Mar 89 18:19:37 PST
Received: from Orange.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 2 Mar 89 18:10:13-PST
Received: by Orange.stanford.edu (5.59/25-eef) id AA04629; Thu, 2 Mar 89 18:10:07 PDT
Date: Thu, 2 Mar 89 18:10:07 PDT
From: Jeffrey Eppinger <jle@Orange.stanford.edu>
Message-Id: <8903030210.AA04629@Orange.stanford.edu>
To: csd-list@score
Subject: CS Colloquium
The next Computer Science Colloquium will be on March 14th:
The Computer Productivity Paradox
Michael L. Dertouzos
Professor and Director
MIT Laboratory for Computer Science
Computer Science Colloquium
Tuesday, March 14, 1989, 4:15pm
Jordan Hall (Building 420), Room 040
Stanford University
(Refreshments will be provided)
Abstract
The first half century of the computer field has been largely supply side
driven by a wondrous new technology that is still evolving and continues
to fuel our imagination. One side of the paradox lies in the apparent
lack of aggregate effect (either up or down) of computers on conventional
measures of human productivity. The other side of the paradox lies in the
indifference of makers and users of computer hardware and software about
the effect of such systems upon human productivity. The talk will examine
how computers might help current productivity weaknesses especially of the
white collar kind, how they might open new productive endeavors, how they
should not be misused and how information might be valued so that we can
develop effective measures of information-processing productivity. The
mission ahead is historic--to apply computer science and information
technology across the world's entire economic front so as to increase
human productivity. The associated question is equally ominous:
Can it be done?
∂02-Mar-89 1909 X3J13-mailer cs proposal and straw vote
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Mar 89 19:09:09 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 549840; Thu 2-Mar-89 22:06:27 EST
Date: Thu, 2 Mar 89 22:06 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: cs proposal and straw vote
To: Dan L. Pierson <pierson@mist.encore.com>
cc: baggins@ibm.com, x3j13@SAIL.STANFORD.EDU
In-Reply-To: <8903012050.AA11442@mist.>
Message-ID: <19890303030636.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 01 Mar 89 15:49:59 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Issue: CHAR-INT-ONLY-USEFUL-WHEN-ATTRIBUTES-SUPPORTED
Problem: CHAR-INT behavior is CHAR-CODE unless implementation
defined attributes are supported.
Proposal:
Remove CHAR-INT
IF: Moon agrees that this is sufficient for hashing (or I'm convinced that
he's wrong :-)).
This is actually an interesting issue. I was going to say that CHAR-INT
is not needed, because you can use SXHASH. After all, in any reasonable
implementation SXHASH of a character would just return the CHAR-INT, and
the only difference would be the extra cost of a type dispatch, which
might even be compiled out in some cases. Then I tried the most
reasonable implementation I know and found that SXHASH and CHAR-INT did
not return the same value. So then I did what I should have done at the
beginning, and read the documentation of SXHASH. SXHASH doesn't just
return any useful hash code, it returns one that remains constant for
all time, within "the same" implementation. This means that in any
implementation that dynamically assigns numeric encodings of any
character attribute, SXHASH cannot be the same as CHAR-INT. Genera, for
example, allows user-defined character registries and user-defined
character style attributes, and thus dynamically assigns the numeric
encoding of both character code and character style.
There are many applications of hashing for which the perpetual equality
properties of SXHASH are unwanted, and the associated efficiency cost
is undesired.
So now my opinion is that CHAR-INT should be retained, but INT-CHAR
and its shadow in the COERCE function should be removed.
What do STRING-LESSP, etc. mean for non-standard-character strings?
Isn't STRING-LESSP defined in terms of CHAR-LESSP? CHAR-LESSP has "the
results are unspecified" for two characters in different registries, I
assume, which means that STRING-LESSP of two strings of extended
characters in the same registry is perfectly well defined, and of
characters in different registries returns either true or false, but is
harmless.
∂02-Mar-89 1929 X3J13-mailer answer to request for comments on comments on comments on characters
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Mar 89 19:28:57 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 549853; Thu 2-Mar-89 22:26:02 EST
Date: Thu, 2 Mar 89 22:26 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: answer to request for comments on comments on comments on characters
To: Thom Linden <baggins@IBM.com>
cc: Common Lisp mailing <x3j13@SAIL.STANFORD.EDU>
In-Reply-To: <890222.100432.baggins@almvma>
Message-ID: <19890303032620.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
In your comments on my comments on the 1 Jan 89 character proposal,
you asked some questions. Here are my answers. These are personal
answers rather than Symbolics' official position.
Date: Wed, 22 Feb 89 10:04:32 PST
From: Thom Linden <baggins@IBM.com>
>> From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
>> Subject: Comments on the Character proposal dated January 1, 1989
>>
>> The default for :ELEMENT-TYPE has two viable choices that I can see
>> both and let people vote:
>>
>> (1) CHARACTER. This matches the behavior of MAKE-STRING and friends,
>> (2) The most natural type for the particular pathname being opened.
>> The relationship of option 2 to :ELEMENT-TYPE :DEFAULT (a feature that
>> already exists in Common Lisp) needs to be clarified. Perhaps they
>> are the same.
The same? I don't understand. For example, I can imagine the
element-type default as base-character and the external format
defaulted to either an ASCII or EBCDIC encoding.
I think you misunderstood. I was suggesting that perhaps the default
value for the :ELEMENT-TYPE option to OPEN should be the symbol
:DEFAULT. This doesn't relate to the external coding format as far as I
can see, except for whatever niceness we see in having the default
value for both :ELEMENT-TYPE and :EXTERNAL-CODED-CHARACTER-FORMAT be the
symbol :DEFAULT.
I see that in the 21 Feb 89 proposal you have made the default value for
the :ELEMENT-TYPE option to OPEN be implementation dependent, but not
:DEFAULT. In fact they are different, because :DEFAULT can open in
either a character type or an integer type, but (the unnamed) default
can only open in a character type. I can live with what you have
proposed, although I still believe that requiring :ELEMENT-TYPE to
default to CHARACTER might be better, and I'm a little concerned about
having a default for which there is no name within the language. I'd
also like to hear opinions on whether we need two different ways to say
"the most natural type for the particular pathname being opened", with
one of them restricted to subtypes of CHARACTER and the other
unrestricted.
More importantly, though, I think people should be given the choice
of voting between the two options mentioned above (as well as any other
options that garner some support, if there are any). As it stands
the :ELEMENT-TYPE option to OPEN isn't in the straw ballot at all,
there's just a change in the back of the proposal.
>> Also the following promise from 14 November did not show up in the report:
>>
>> >> There should be a name for the "natural" encoding and there should be a
>> >> specification of the properties of the natural encoding that a programmer
>> >> can rely on. Suggestions for the name include :BASE, :NATURAL, and
>> >> :INTERCHANGE. The definition probably involves the concept of data
>> >> interchange with non-Lisp programs on the same system.
>>
>> This will be added to the revision.
I lied. No one came up with the 'properties' of such an encoding.
Do you have some text to suggest?
I'm not sure if your :DEFAULT for :EXTERNAL-CODED-CHARACTER-FORMAT is
intended to be "natural" as well as "default", or not. I'm afraid
I haven't been able to come up with a good description of what it
means to be "natural", though. Perhaps I'm familiar with too many
oddball systems, which makes me more scared of trying to define the
concept than would be someone who only knew Unix. I think we can
safely drop this issue without much harm to the language.
>> No particular page -- We agree with the deprecation or deletion of the two
>> particular character attributes defined by CLtL, but not with the
>> deprecation of the whole concept of character attributes. In fact on page
>> 20 you say "characters are uniquely distinguished by their codes," which
>> makes it impossible to have character attributes at all. The language must
>> define how conforming programs should be written so that they will work
>> both in implementations with character attributes and in implementations
>> without them. For example, the value of (eql x (code-char (char-code x)))
>> is unspecified. Another thing that needs to be said is that the exact
>> character operations (char=, string=, etc.) respect all character
>> attributes, while the inexact character operations (char-equal,
>> string-equal, etc.) respect or ignore each character attribute in an
>> implementation-defined but consistent fashion.
This has improved in the 21 Feb 89 version, but I think more a explicit
statement is still required. You are welcome to borrow the language
("exact", "inexact") that I used just above.
Some of what you say on
>> page 44 about attributes in general needs to be part of the spec, not
>> deprecated. I would retain everything on that page except for INT-CHAR and
>> the last bullet (referring to bits and fonts), and I would add a remark
>> that FIND-SYMBOL and INTERN respect character attributes. If you want,
>> perhaps I or someone else at Symbolics can provide exact text for what
>> to say about character attributes that you could insert into your report.
I moved the attribute list previously in Appendix B back into the
description of characters. Let me know what text you would like
to see for FIND-SYMBOL and INTERN and I'll add it to the list.
After "It is implementation dependent whether attributes are removed
from symbol names by READ" (and by the way, in this and the preceding
bullet I believe "whether" shoudl be changed to "which", since an
implementation with several character attributes might have good reason
to remove some and retain others), I would add "The functions FIND-SYMBOL
and INTERN do not remove character attributes."
∂02-Mar-89 1941 CL-Characters-mailer Really about TYPEP failures: Comments on the Character proposal dated January 1, 1989
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Mar 89 19:41:42 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 549857; 2 Mar 89 22:39:01 EST
Date: Thu, 2 Mar 89 22:39 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Really about TYPEP failures: Comments on the Character proposal dated January 1, 1989
To: Robert W. Kerns <RWK@FUJI.ILA.Dialnet.Symbolics.COM>
cc: Jon L White <jonl@lucid.com>, Baggins@IBM.COM, CL-Characters@SAIL.STANFORD.EDU,
X3J13@SAIL.STANFORD.EDU, Common-Lisp-Implementors@Symbolics.COM, KMP@Symbolics.COM,
Palter@Symbolics.COM
In-Reply-To: <19890204142708.2.RWK@CALVARY.ILA.Dialnet.Symbolics.COM>
Supersedes: <19890303023922.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comments: Removed % signs
Message-ID: <19890303033902.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sat, 4 Feb 89 09:27 EST
From: Robert W. Kerns <RWK@FUJI.ILA.Dialnet.Symbolics.COM>
Legitimate operations on BASE-CHARACTER do not
produce characters in (AND CHARACTER (NOT BASE-CHARACTER)).
I'm not sure which programs written using symbols in the LISP package
are "legitimate operations" and which are not. However, I didn't see
anything in the 21 Feb 89 proposal that says that CHAR-UPCASE of
a BASE-CHARACTER is necessarily a BASE-CHARACTER, for example.
That doesn't sound unreasonable, though; should it be added?
∂02-Mar-89 2119 LOGMTC-mailer Logic seminar
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Mar 89 21:19:12 PST
Received: by csli.Stanford.EDU (4.0/inc-1.0)
id AA01637; Thu, 2 Mar 89 21:17:04 PST
Date: Thu 2 Mar 89 21:17:03-PST
From: Sol Feferman <SF@CSLI.Stanford.EDU>
Subject: Logic seminar
To: Logic@csli.Stanford.EDU
Message-Id: <604905423.0.SF@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
Logic Seminar
Speaker: Prof. Yuri Gurevich, Univ. of Michigan, visiting Stanford and IBM
Title: Average case computational complexity
Time: Tuesday, March 7, 4:15-5:30 PM
Place: Room 381-T, Math Corner, Stanford University
Abstract:
One way to cope with an NP hard problem is to consider a randomized
version of the problem, i.e., a problem together with a probability
distribution on instances. Even if the original problem is NP hard,
it may happen that the randomized problem is solvable in expected
polynomial time. In 1984, Leonid Levin generalized NP completeness
theory to the case of randomized NP problems and constructed a fairly
natural problem complete for Randomized NP. Then the speaker found
additional complete problems and caused certain revision of the
theory. We will explain the basic definitions and survey the current
state of the theory.
-------
∂03-Mar-89 0004 X3J13-mailer cs comments
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 3 Mar 89 00:03:57 PST
Date: Thu, 02 Mar 89 17:19:25 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <x3j13@sail.stanford.edu>
Message-ID: <890302.171925.baggins@almvma>
Subject: cs comments
>> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>> Subject: minor comments on the character proposal
>>
>> These comments are not an official response to your request for a vote.
>>
>> Here are some comments on the character proposal version of 21 Feb 89.
>> I believe these are all merely editorial, but if they are matters of
>> disagreement I'd like to know.
>>
>> p.29, describing character attributes: It needs to be clarified that
>> these notes apply to all implementation-defined character attributes,
>> not just to attributes that might be provided for compatibility with
>> the earlier version of Common Lisp.
Ok.
>>
>> Some of these notes have not been consistently reflected elsewhere in
>> the proposal, for example, page 31 seems to say that the only difference
>> between char-equal and char-= involves alphabetic case, whereas page 29
>> says that char-= compares all attributes but char-equal compares an
>> implementation-defined set of attributes (page 29 is correct).
>> Similarly, where p.31 says "if the codes of two characters differ, then
>> they are different", it should instead say "if the codes or
>> implementation-defined attributes (if any) of two characters differ,
>> then they are different."
The intent was that p29 defined all the modified behaviors when
implementation-defined attributes were supported. I could repeat these
notes (through modified text) at each of the referenced locations or
make the intent of p29 stronger. Which do you feel is clearer?
>>
>> Two of the notes on p.29 refer to char-int and int-char, which you are
>> proposing to remove, so those notes should be removed.
Correct.
>>
>> p.33, 35: Under find-char, char-registry-name, and char-label you
>> indicate that registry names and labels are strings. In fact they
>> are symbols now, these places need to be updated.
Right.
>>
>> p.38: Where it says "an implementation may support names of the
>> form label:registry", I believe this to be a typo for "registry:label".
>> The colon is evidently being used by analogy to packages, so the
>> registry name should precede the label, just as the package name
>> precedes the symbol name.
>>
Ok.
∂03-Mar-89 0726 @Score.Stanford.EDU:tom@polya.Stanford.EDU NeXT Machine moving
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Mar 89 07:26:54 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Fri 3 Mar 89 07:24:13-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA01847; Fri, 3 Mar 89 07:24:14 -0800
Date: Fri, 3 Mar 89 07:24:14 -0800
From: Tom Dienstbier <tom@polya.Stanford.EDU>
Message-Id: <8903031524.AA01847@polya.Stanford.EDU>
To: CSD@polya.Stanford.EDU, Faculty@polya.Stanford.EDU
Subject: NeXT Machine moving
The NeXT machine that was sitting outside James Wilsons old office
has been moved to downstairs. It will be set up in room 030 as soon as we
can figure out how to secure it(not obvious on how to chain it down).
We are planning on hooking it up to the MJH network to make it a more
functional machine.
Tom Dienstbier
∂03-Mar-89 0913 X3J13-mailer cs comments
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Mar 89 09:13:20 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 550140; Fri 3-Mar-89 12:10:42 EST
Date: Fri, 3 Mar 89 12:10 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: cs comments
To: Thom Linden <baggins@IBM.com>
cc: Common Lisp mailing <x3j13@SAIL.STANFORD.EDU>
In-Reply-To: <890302.171925.baggins@almvma>
Message-ID: <19890303171050.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 02 Mar 89 17:19:25 PST
From: Thom Linden <baggins@IBM.com>
>> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>> Subject: minor comments on the character proposal
>>
>> Some of these notes have not been consistently reflected elsewhere in
>> the proposal, for example, page 31 seems to say that the only difference
>> between char-equal and char-= involves alphabetic case, whereas page 29
>> says that char-= compares all attributes but char-equal compares an
>> implementation-defined set of attributes (page 29 is correct).
>> Similarly, where p.31 says "if the codes of two characters differ, then
>> they are different", it should instead say "if the codes or
>> implementation-defined attributes (if any) of two characters differ,
>> then they are different."
The intent was that p29 defined all the modified behaviors when
implementation-defined attributes were supported. I could repeat these
notes (through modified text) at each of the referenced locations or
make the intent of p29 stronger. Which do you feel is clearer?
I feel strongly that in the eventual language standard, it will not be
acceptable to have two sections that speak inconsistently about the same
thing, with the reader told that one section takes precedence over the
other. Thus in the eventual document, this kind of information must be
repeated (at least by reference) at each occurrence. For example, you
can't say in one place "char-equal is the same as char-= except it ignores
alphabetic case" and then say in another place "the other description
of char-equal was simplified for your comfort and convenience, the real
description is char-equal is the same as char-= except it ignores
alphabetic case and some implementation-defined character attributes."
I'm not sure what this says about your document, which is so far from
being in the form of the eventual language standard. It is very
difficult to know whether we are voting on chapters 1 and 2 of the
document, on appendix A of the document, or on the abbreviated "cleanup
issues" in your straw poll. If we're not voting on Appendix A there
is little advantage in spending time making it self-consistent.
Some observers may be wondering why I want implementation-defined
attributes to be discussed in the standard, instead of merely being
defined by the implementations. The issue is to make it possible to
write programs that are both conforming and portable among
implementations with varying implementation-defined attributes, without
the programmer first having to study and compare the documentation of
all the implementations. In other words, the Common Lisp language
standard should define the framework for implementation-defined
character attributes, and the individual implementations should just
fill in that framework. If the language didn't mention the possible
existence of implementation-defined character attributes, it would
be too easy to write a program that at first seemed conforming, but
in fact would not behave as desired on an implementation with
character attributes.
∂03-Mar-89 1006 X3J13-mailer Issue: ERROR-TERMINOLOGY
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 3 Mar 89 10:06:46 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA03990g; Fri, 3 Mar 89 10:00:10 PST
Received: by challenger id AA20493g; Fri, 3 Mar 89 09:55:26 PST
Date: Fri, 3 Mar 89 09:55:26 PST
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8903031755.AA20493@challenger>
To: x3j13@sail.stanford.edu
Subject: Issue: ERROR-TERMINOLOGY
I looked at the error terminology section as if I were the editor of
the specification, and I made some further changes. I had made an
earlier pass over the material that was intended to tighten it up, but
one can almost always continue to improve things. I showed this draft
to Moon and he said ``I am entirely happy with your proposed rewording
of the error terminology.''
The remainder of this message contains the proposed rewording:
Issue: ERROR-TERMINOLOGY
References: Chapter 5, Section 5.1, Working draft of the standard
CLOS Chapter 1
CLtL Chapter 1, Section 1.2.4
Condition System, Version 18
Category: Clarification
Edit history: 27-DEC-88, Version 1 by Chapman
31-JAN-89, Version 2 by Chapman
6-FEB-89, Version 3 by Chapman, RPG and Barmar comments included
8-FEB-89, Version 4 by Chapman, added more to Current Practice
21-FEB-89, Version 5 by Chapman, added van Roggen, RPG comments
3-MAR-89, Version 6 by Gabriel, rewrite prompted by Moon
Problem Description:
In CLtL, CLOS and the Condition System, similar but slightly
different language is used to describe
non-normal actions by CL operators. The X3J13 committee needs to
agree on a standard set of terms and their meanings.
Proposal (ERROR-TERMINOLOGY:STANDARD TERMS)
TERM MEANING
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
CONFORMING CODE (*) Code that adheres to the following requirements:
(1) Conforming code shall not use any constructions
that are prohibited by the standard.
(2) Conforming code shall not depend on extensions
included in an implementation.
SAFE CODE (*) Code processed with the SAFETY optimization at its
highest setting. SAFETY is a lexical property of code.
UNSAFE CODE (*) Code processed with lower safety levels.
Note: Unsafe code is not necesarily code that does
not do error checking: Implementations are
permitted to treat all code as safe code all the time.
IS SIGNALLED An error is signalled in both safe and unsafe code.
Conforming code may rely on the fact that the error
will be signalled in both safe and unsafe code.
Every implementation is required to detect the error
in both safe and unsafe code. For example, "an error
is signalled if UNEXPORT is given a symbol not
accessible in the current package."
SHOULD BE SIGNALLED An error will be signalled in safe code, and an error
might be signalled in unsafe code.
Every implementation is required to detect the error
at least in safe code. When the error is not
signalled, the "consequences are undefined" (see
below). For example, "an error should be signalled
if ENDP is given a non-list argument."
CONSEQUENCES ARE UNSPECIFIED The consequences are unpredictable but harmless.
Implementations are permitted to specify the
consequences of this situation. No conforming code may
depend on the results or effects of this situation,
and all conforming code is required to treat the
results and effects of this situation as unpredictable
but harmless. For example, ``the consequences of the
garbage collector when invoked are unspecified.''
CONSEQUENCES ARE UNDEFINED The consequences are unpredictable. The
consequences may range from harmless to fatal. No
conforming code can depend on the results or
effects. Conforming code must treat the results and
effects as unpredictable. In places where the
words "must", "must not" or "may not" are used,
then "the consequences are undefined" if the stated
requirement is not met, and no specific consequence
is explicitly stated. For example: "Once a name
has been declared by DEFCONSTANT to be constant,
any further assignment or binding of that special
variable has undefined consequences."
RETURN VALUES ARE UNSPECIFIED Only the number and nature of the return values
of a construct are not well specified but any
side-effect and transfer-of-control behavior is well
specified. For example, if the return values of some
function F are unspecified, then an expression such as
(length (list (F))) is still well-specified because it
does not rely on any particular aspect of the value or
values returned by F.
IMPLEMENTATIONS MAY BE EXTENDED An implementation is free to treat the
situation in ANY ONE of the following ways: (1)
When the situation occurs, an error is signalled at
least in safe code, OR (2) When the situation
occurs, the "consequences are undefined", OR (3)
When the situation occurs, the consequences are
defined. Also, no conforming code can depend on
the results or effects of this situation, and all
conforming code must treat the results and effects
of the situation as undefined. For example,
"implementations may be extended to define other
type specifiers to have a corresponding class."
FREE TO EXTEND THE SYNTAX Implementations are permitted to define unambiguous
extensions to the syntax of the construct being
described. No conforming code can depend on this
extension. All conforming code is required to treat
the syntax as meaningless. The standard may disallow
certain extensions while allowing others. For example,
"no implementation is free to extend the syntax of
DEFCLASS."
WARNING IS ISSUED A warning is issued, as described in WARN, in both
safe and unsafe code and when the situation is
detected by the compiler. Conforming code may rely
on the fact that a warning will be issued in both
safe and unsafe code and when the situation is
detected by the compiler. Every implementation is
required to detect this situation in both safe and
unsafe code and when the situation is detected by
the compiler. The presence of a warning will in no
way alter the value returned by the form which
caused the situation to occur. For example, "a
warning is issued by the compiler if a declaration
specifier is not one of those defined in Chapter 9
of CLtL and has not been declared in a DECLARATION
declaration."
WARNING SHOULD BE ISSUED A warning may be issued. Conforming code may not
rely on the fact that a warning will be issued. If
the situation is detected by the compiler, a
warning may or may not be issued, depending on the
implementation. The presence of a warning will in
no way alter the value returned by the form which
caused the situation to occur. For example, "a
warning should be issued by a compiler if a
variable declared to be ignored is referenced
or is also declared special, or if a variable is
lexical, never referenced, and not declared to be
ignored."
(*) means this term is used to define other terms in this proposal,
not explicitly used in the standard.
∂03-Mar-89 1032 @polya.Stanford.EDU:tah@linz Theory Faculty Candidate
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Mar 89 10:32:49 PST
Received: from linz.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA08864; Fri, 3 Mar 89 10:29:34 -0800
Received: by linz.stanford.edu (5.59/25-eef) id AA08029; Fri, 3 Mar 89 10:28:43 PDT
Message-Id: <8903031828.AA08029@linz.stanford.edu>
To: thcom@sail, csd@score, aflb-all@polya
Subject: Theory Faculty Candidate
Date: 03 Mar 89 10:28:40 PST (Fri)
From: Tom Henzinger <tah@linz>
Joe Kilian (M.I.T.) will be visiting on Monday and Tuesday, March 6-7.
Please send me a message if you want to talk with him, and/or join him
for lunch/dinner.
His schedule so far:
Tu 12:00 lunch with students
4:15 AFLB talk
∂03-Mar-89 1127 chandler@polya.Stanford.EDU CSD Retreat
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Mar 89 11:27:27 PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA11653; Fri, 3 Mar 89 11:24:47 -0800
Date: Fri, 3 Mar 1989 11:24:44 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: retreat@polya.Stanford.EDU
Subject: CSD Retreat
Message-Id: <CMM.0.87.604956284.chandler@polya.stanford.edu>
Time is drawing near for me to make confirmed reservations at Chaminade in
Santa Cruz for our up-coming retreat May 5-7. For those of you (and you are
MANY) who have not already done so, PLEASE LET ME KNOW:
1. Will you attend?
2. If so, will you require single or double accommodations?
3. If single accommodations, please provide me with an account number and
name to charge the difference in rates.
To those of you who have already responded, "thank you".
∂03-Mar-89 1130 X3J13-mailer Re: Section 1.7
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 3 Mar 89 11:30:17 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA13011; Fri, 3 Mar 89 11:28:34 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA12864; Fri, 3 Mar 89 11:24:49 PST
Received: by clam.sun.com (4.0/SMI-4.0)
id AA26139; Fri, 3 Mar 89 11:27:58 PST
Date: Fri, 3 Mar 89 11:27:58 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903031927.AA26139@clam.sun.com>
To: barmar@Think.COM, pierson@mist.encore.com
Subject: Re: Section 1.7
Cc: chapman%aitg.DEC@decwrl.dec.com@Multimax.encore.com,
skona%csilvax@hub.ucsb.edu@multimax.encore.com,
x3j13@sail.stanford.edu
I agree with Barry. Packages not named in the standard belong
to software developers. Otherwise every name defined by anyone
becomes an extension to Common Lisp, and I don't think we want
to define "extension" that way.
∂03-Mar-89 1202 X3J13-mailer Common Lisp
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 3 Mar 89 12:02:33 PST
Received: from fafnir.think.com by Think.COM; Fri, 3 Mar 89 14:56:49 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 3 Mar 89 14:58:31 EST
Received: by verdi.think.com; Fri, 3 Mar 89 14:55:18 EST
Date: Fri, 3 Mar 89 14:55:18 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903031955.AA21691@verdi.think.com>
To: moore@cli.com
Cc: x3j13@sail.stanford.edu
Cc: Steele@Think.COM
In-Reply-To: J Strother Moore's message of Fri, 3 Mar 89 10:44:34 CST <8903031644.AA08035@client13.CLI.COM>
Subject: Common Lisp
Date: Fri, 3 Mar 89 10:44:34 CST
From: J Strother Moore <moore@cli.com>
I just wanted to let you know that I love Common Lisp.
I have used it a lot this past year extending Boyer's and
my theorem prover and the more I've used it the more I
like it. You guys really did a great job.
J
Thank you very much for the compliment. ANSI committee X3J13
is working to clean up the rough spots and fill in the gaps;
I hope you like the revision as much as the current definition.
And of course lots of credit must go to the implementors.
This mail made my day.
--Guy Steele
∂03-Mar-89 1221 X3J13-mailer KMP's personal comments on 22-Feb-89 Character Proposal
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Mar 89 12:21:23 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 550353; Fri 3-Mar-89 15:17:40 EST
Date: Fri, 3 Mar 89 15:17 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: KMP's personal comments on 22-Feb-89 Character Proposal
To: Baggins@IBM.COM
cc: X3J13@SAIL.Stanford.EDU
References: <19890303165649.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890303201737.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Please find below my personal comments on the hardcopy character
proposals of 22-Feb-89 which I received from you by US Mail.
This is not the Symbolics official position. Moon will send that
at a later date.
Note that this will be my only mailing to this large list on this
issue prior to the meeting. If I have anything further to say, I
will bring it up on CL-Characters or some smaller list. I expect,
however, that my attention will be focused on other issues.
By the way, you still have my old address (11 Cambridge Center).
The correct new address for me, Moon, and Symbolics R&D is:
8 New England Executive Park, East
Cambridge, MA 01803-5007
----- Comments on the Isolated Proposals (hardcopy of 22-Feb-89) -----
Presentational Comments
- This doesn't follow the normal proposal format being used by
other groups. As a consequence...
- there are no examples to make certain sticky points clearer
- there is no impact analysis
- there is no rationale for some of the questionable changes
I think it is unreasonable to expect people to just infer this
kind of thing. Reasoning about these things takes a lot of time.
Writing down your thoughts once you've reasoned about something
takes much less time than asking someone to repeat your entire
process in order to decide if they approve.
Also, there is precedent for making decisions in language design
that later are suggested to be mistakes. Often it is hard to
distinguish `changing goals' from `poor communication' from
`oversight' from `typo.' Our normal proposal format is designed
to avoid some of these symptoms by making explicit some things
that would not be explicit in the final document, and by adding
redundancy that helps catch typos, miscommunication, etc.
- The proposal descriptions are far too brief. They are prone to
misinterpretation. Worse, an `expansion' does not occur elsewhere.
Often to disambiguate you have to do a lot of digging around and
assembling things from pieces here and there.
At the very least, there should be index information from these
short punchy phrases to something less ambiguous. Better still
would be to really spell out the details in the proposal so that
they can be examined in the abstract.
Breaking this big proposal up into little ones should have
accomplished two things: it should have allowed us to understand
the parts of the proposal in isolation, and it should have allowed
independent voting. I think it currently allows neither, because
you can't understand the individual proposals without understanding
the whole and if you vote No on any particular part, you aren't left
with a document that Kathy can usefully work with.
Technical Comments
- Regarding defining that STRING-CHAR must be either BASE-CHAR or
CHARACTER -- This seems unmotivated and I am suspicious of it.
It seems, somehow, unnecessarily restrictive.
- I don't mind if INT-CHAR is removed, but I don't think CHAR-INT
should be removed. It may be useful in some hashing applications.
- Regarding the problem description in CHARACTER-TYPE-RESTRICTIVE,
I don't think that I believe that CHARACTER doesn't allow both fat
and thin characters. Is this claim motivated somewhere.
- The proposal CHARACTER-TYPE-RESTRICTIVE suggests replacing
STANDARD-CHAR by (CHARACTER :STANDARD), but since STANDARD-CHAR
is not really going away, this wording is misleading.
- Proposals STRING-TYPE-RESTRICTIVE and SIMPLE-STRING-TYPE-RESTRICTIVE
refer to making STRING and SIMPLE-STRING (respectively) union types.
The details of this are never spelled out. The consequences are not,
I think, appropriately analyzed. I would like to better understand the
relationship between this and the new array TYPEP situation to make
sure there are no bad interactions.
- I do not understand from the description of
SIMPLE-STRING-TYPE-ABBREVIATIONS why adding SIMPLE-BASE-STRING
and SIMPLE-GENERAL-STRING is an answer to the problem that new types
are awkward to name.
Aesthetic Comments
- I think the terms `coded character format' and `coded character set'
are ok for a concept description, but inappropriate for a language spec.
They are too long for convenient lunch table discussion, note taking,
etc. If you want something to be part of a language that people use in
a serious way, you have to either truncate the terms to manageable
size or expect people to do it for you. If you do it, at least that
visitors from other companies will be able to participate in lunch
table discussions. If you let your users do it, there will be lots of
gratuitous variation. The impact of this is that...
- In FILE-EXTERNAL-REPRESENTATION, :EXTERNAL-CODED-CHARACTER-FORMAT
is far too long. In any situation, such as with OPEN, where the
space of keywords is not user-extensible, the need for
extraordinarily long names is very low because short names can
adequately disambiguate. I see no reason why some much shorter
keyword cannot be devised. (Just for your reference, even
:IF-DOES-NOT-EXIST tries my patience.)
I suggest :EXTERNAL-ENCODING as a straw man, but all I really care
about is that it be a minimal number of words, and I don't think
the proposed choice is short enough.
- In STRING-BINARY-WIDTH, I think the name EXTERNAL-CODED-STRING-LENGTH
is again too long. It's not like people will ever add symbols to
the LISP package, so it's not like a shorter name would be ambiguous.
I suggest STRING-ENCODED-LENGTH (to match my :EXTERNAL-ENCODING above).
- In CHAR-CODE-NON-PORTABLE, I very strongly dislike abbreviations except
in extraordinary circumstances like `char' where the abbreviation is
nearly ripe for adoption as an English word due to its extremely wide,
or where the word is used so often that spelling it out would be too
awful.
However, if you spell it out, I'll complain that it is too long a term.
I propose you call the thing CHAR-ENCODING.
- In CHARACTER-IDENTIFICATION-NONPORTABLE, I don't think you've necessarily
solved anything if you say that (a) all characters must come from some
registry and (b) all registries must be dicated by an ISO group that doesn't
exist. It necessarily follows that there can be no correct implementation
until that working group finishes. What are people to do in the interim?
It either needs to be spelled out, or it needs to be explained why what they
do doesn't matter. [And, indeed, if it doesn't matter, then it's going to be
hard to make the case that a lot of the existing rules are really necessary.]
Typos
- In CHARACTER-TYPE-RESTRICTIVE, defining BASE-CHARACTER as a subtype
of STRING seems like an extraordinarily bad idea. :-)
- In STRING-BINARY-WIDTH, presumably the function name does not want
to be in the KEYWORD package.
----- Comments on the Concept Part (hardcopy of 22-Feb-89) -----
Presentational Comments
- The proposal uses the term "removed" a lot but that sometimes seems to
mean "gets totally rid of", sometimes means "deprecates", sometimes
means "adds something that's really better". Maybe I'm just misreading,
but it would be helpful in terms of being a proposal that people have to
vote on, to clearly define these terms.
- I am actually offended by the use of these tags like ISO8859/2-1987
with no exposition. This gives a `snobby' look to the paper and amounts
to jargon because it is not intelligible by people who are on in on
ISO affairs. I feel forced to write to ISO to get these documents just
to know what you're talking about. I have no sense for whether you are
talking about something I'm familiar with under another name, or
something totally irrelevant to me. I made annotations all over the
document about this. It was really starting to bug me.
- p9, last two paragraphs before 2.3 should be a single paragraph.
- I found it hard to read about REGION-SPECIALIZED-STRING, GENERAL-STRING,
etc. and then to think that you weren't in fact proposing it. Someone
skimming would probably miss the word `hypothetical' ... Especially since
my vague recollection is that this stuff was really in a previous proposal,
I think this stuff either be much more clearly set off as an example.
Technical Comments
- From a human interface standpoint, I think it would be desirable for
character repertoires to have more than one possible name. My guess
is -- though I have no way of proving it since no hint is given about
what names these things refer to -- that these things have more common
nicknames that would be more programmer-friendly if allowed. Names made
up of mostly digits are not appealing to me.
- If people can add non-stanard registries, there is a potential for
confusion. If I add a private registry named FOO and then at a later
time ISO votes in a registry named FOO, mine will suddenly appear to
be the official one. If there a way to tell official ones from unofficial
ones, that might avoid some problems down the road. Alternatively, if
a portion of the registry namespace were allocated for ISO (or,
conversely, reserved for private use), that would solve the problem.
- The fact that character labels must be uniquely named using only
standard-char-p characters strikes me as having funny bootstrap
implications. I don't know what if anything to do about that, but I
thought I'd mention it.
- The issue of character labels also makes me wonder about uses of
special chars like colon, backslash, semicolon, dollarsign which often
have special meaning to Lisp and other languages. Further, the use
potential to use underscore and hyphen seems like a bad idea, too,
because some systems prefer underscore to hyphen -- and vice versa.
Personally, I think we ought to say that character labels have to be
made of A to Z, a to z, and 0 to 9 (with preference for alphabetics
over numerics -- i.e., they should try to be actual words).
- Also, who will assign character labels? Will they not be standard
across implementations? This is a place where examples of sample uses
would help a lot.
- I couldn't make sense of the cryptic phrase `Reader Canonicalization'
in a bullet item at bottom of chap 2, page 8. I think this should
be elaborated.
- I've wrestled with this business of (and character (not base-character))
a lot and come to the conclusion that you should give this a name
in the language itself. e.g., you should deftype the name
extended-character. The reasons are these:
- so it can be used in discussions, bug reports, etc.
- so that there is a term that could be common between lisp and some
other language -- where the other language was non-lispy and a lisp
AND expression would not be welcome.
- When the external encoding is not reliably using a single-byte format,
you need to specify the consequences for the functions FILE-POSITION
and FILE-LENGTH.
- Is $ really what is replaced by the British pound sign on British
displays? I had always thought that # was what was replaced. My point,
though, is that there may be more than one axis on which to view
`equivalent functionality.'
I don't think I'm disagreeing with you on the details here, but I am
saying that I don't think it's as pretty a picture as you paint it,
and that (like the `pathnames' section in CLtL) you risk making people
think they're getting a more comfortable solution than they're really
getting.
I think the real point here should be that this is a thing which
gratuitously varies in the marketplace and in the world, that we don't
have a prayer of standardizing it, and we're leaving it up to vendors
to do the best they can.
I have a couple of specific questions, though:
- What if a program that on American terminals types out:
That will cost $4.00
types out
That will cost L4.00
on a british screen. I'm not so sure I'm happy with that.
- What about _ vs -. Some computer systems seem to take languages
that are defined to distinguish case (and be all uppercase) and
invert the case (make it all lowercase), often flipping hyphen
and underscore, and single and doublequote in the process. Are
these valid transformations?
- top of p13, you say that the COERCE function is extended to allow
for coercion from base string to extended string. Be explicit about
how this is done.
- Regarding footnote 18 on p13, my personal feeling is that either all
conventions should be itemized or none should. If none are, you can
pick obviously hypothetical names. However, I think that to mention
one or two encodings and not others amounts at best to advertising
and at worst can either pin an implementation unnecessarily (by having
an external document such as CLtL or the ANSI CL spec define something
which might want to vary over time) or can cause a market bias toward
implementations which have their convention mentioned over implementations
which do not have their conventions mentioned.
- The whole issue of non-graphic characters is almost totally omitted
from the discussion. I think more should have been said. A parenthetical
remark about #\Newline at top of p14 of chap 2 is about all there seemed
to be.
- I think the reason that EXTERNAL-CODED-STRING-LENGTH does not address
the problem of screen width in proportional fonts should be addressed.
Is an implication also that Huffman coding (is that how you spell it)
in stream output is also not addressed (or possibly illegal) because
it is context sensitive?
Typos
- You've put some function names in italic where you meant code-font.
e.g., in Section 2.1
-----
Due to time constraints, I only skimmed the editorial modifications to
CLtL in trying to get answers to specific questions I ran into in the
other parts. The absence of remarks about those changes shouldn't
necessarily be construed at this time as approval on my part.
∂03-Mar-89 1226 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Final Program-Complexity Symposium
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Mar 89 12:26:01 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA15677; Fri, 3 Mar 89 12:23:17 -0800
Message-Id: <8903032023.AA15677@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Fri, 3 Mar 89 12:23:38 PST
Received: by BYUADMIN (Mailer R2.01A) id 8955; Fri, 03 Mar 89 06:45:58 MST
Date: Thu, 2 Mar 89 23:19:48 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Joe Traub <traub@CS.COLUMBIA.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Joe Traub <traub@CS.COLUMBIA.EDU>
Subject: Final Program-Complexity Symposium
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
THIRD SYMPOSIUM ON COMPLEXITY OF APPROXIMATELY SOLVED PROBLEMS
COMPUTER SCIENCE DEPARTMENT
COLUMBIA UNIVERSITY
April 3-5, 1989
SUPPORT: This Symposium is supported by a grant from the National
Science Foundation.
REGISTRATION: The symposium will be held at the Kellogg Conference
Center, on the fifteenth floor of the International Affairs Building,
Columbia University, 118th Street and Amsterdam Avenue. Registration
will start at 9:00 a.m. THERE IS NO REGISTRATION CHARGE.
PUBLICATION: Invited papers will be published in the Journal of Complexity.
FOR FURTHER INFORMATION: If you have any questions, contact Kerny
McLaughlin, Computer Science Department, Columbia University, (212)
854-2736.
SYMPOSIUM SCHEDULE
There will be two hour-long plenary lectures and thirty-four invited
papers as well as contributed papers.
PLENARY LECTURES
MONDAY, APRIL 3, 1989
9:40-10:40 Steven Smale, University of California, Berkeley
"Godel, undecidability, chaos"
2:20- 3:20 Leon N. Cooper, Brown University
"Neural networks in real world applications:
approximate solutions to complex problems"
MONDAY, APRIL 3, 1989
9:00- 9:30 Registration and Coffee
9:30- 9:40 J.F. Traub, Columbia University
Opening Remarks
9:40-10:40 S. Smale, University of California, Berkeley
"Godel, undecidability, chaos"
10:40-11:00 Z. Galil, Columbia University
(with M. Chaimovich & G. Freiman, Tel-Aviv University, Israel)
"Solving the subset-sum problem using analytic number theory"
11:00-11:20 J. Tsitsiklis, Massachusetts Institute of Technology
"The analytic complexity of dynamic programming and
related fixed-point problems"
11:20-11:40 Coffee
11:40-12:00 H. Wozniakowski, Columbia University
(with J. Kuczynski, Polish Academy of Sciences, Poland)
"Estimating the largest eigenvalue by the power and
Lanczos algorithms with a random start"
12:00-12:20 D. Lee, AT&T Bell Laboratories
"Detecting discontinuities"
12:20-12:40 G. Wahba, University of Wisconsin
"Multivariate function estimation and model building
with interaction splines"
12:40- 1:00 D. Donoho, University of California, Berkeley
"A controversy in inverse theory and a solution
via optimal recovery"
1:00- 2:20 Lunch
2:20- 3:20 L. Cooper, Brown University
"Neural networks in real world applications:
approximate solutions to complex problems"
3:20- 3:40 Y. Abu-Mostafa, California Institute of Technology
"Learning from hints in neural networks"
3:40- 4:00 E. Baum, Princeton University
"On learning a union of half spaces"
4:00- 4:20 Tea
4:20- 4:40 G.W. Wasilkowski, University of Kentucky
(with F. Gao, University of British Columbia, Canada)
"On the power of adaptive information for functions
with singularities"
4:40- 5:00 D. Saari, Northwestern University
"On the design of organizations and of distributed
computing algorithms"
5:00- 5:20 A. Werschulz, Columbia University
"Are finite elements optimal on the average?"
TUESDAY, APRIL 4, 1989
9:00- 9:40 Coffee
9:40-10:00 S. Heinrich, Akademie der Wissenschaften der DDR
TBA
10:00-10:20 K. Sikorski, University of Utah
(with H. Wozniakowski, Columbia University)
"An ellipsoid algorithm for fixed point computation"
10:20-10:40 L. Blum, International Computer Science Institute, Berkeley
"NP-completeness over the reals"
10:40-11:00 L. Levin, Boston University
"Almost no linear predicates of witnesses of hard NP
problems have feasible approximations"
11:00-11:20 Coffee
11:20-11:40 B. Kacewicz, University of Warsaw, Poland
(with L. Plaskota, University of Warsaw, Poland)
"Asymptotic optimality of algorithms with noisy information"
11:40-12:00 J.M. Steele, Princeton University
"Complexity of statistical models of images"
12:00-12:20 I. Johnstone, Stanford University
"Speeds of estimation in positron emission tomography
and related inverse problems"
12:20-12:40 J. Kuczynski, Polish Academy of Sciences, Poland
TBA
12:40- 2:00 Lunch
2:00- 3:40 CONTRIBUTED PAPERS
Session 1 Session 2
2:00- 2:20 A.Papageorgiou R.A. Levinson
Columbia University UC Santa Cruz
"Improved sampling "Finding vertex covers
for multivariate of cubic graphs"
integration on the
average"
2:20- 2:40 H. Nakano V. Sarkar
Osaka University, Japan IBM, T.J.Watson Research Center
(with Y. Nakanishi, "Efficient representation
Osaka University, Japan) of a transitive relation
"Statistical estimation by partitioning into complete
of local neighborhood bipartite subgraphs"
search method"
2:40- 3:00 X. Xuan W. Szpankowski
UC Berkeley Purdue University
"On solving a class "Stochastic approximations
of nonlinear BVP's for some combinatorial
with global convergence" problems and their
algorithmic implications"
3:00- 3:20 J. Rolim M. Hatzitheodorou
Odense University, Denmark Columbia University
"Towards a complexity (with T.Jackowski and
theory for approximation A. Papageorgiou, Columbia Univ.)
languages" "A smoothing spline approach
to the shape from shadows
problem"
3:20- 3:40 T. Jackowski V. Rego
Columbia University Purdue University
"Complexity of "On average time bounds for
multilinear problems" some simple random algorithms"
3:40- 4:00 Tea
4:00- 4:20 T. Boult, Columbia University
"On computation of topological degree"
4:20- 4:40 Y. Yomdin, Institute for Advanced Study, Princeton
"Approximative and topological complexity of functions"
4:40- 5:00 L. Plaskota, University of Warsaw, Poland
"On average case complexity of linear problems with
noisy information"
WEDNESDAY, APRIL 5, 1989
9:00- 9:40 Coffee
9:40-10:00 F. Gao, University of British Columbia, Canada
"Probabilistic analysis for numerical algorithms"
10:00-10:20 M. Milanese, Politecnico di Torino, Italy
(with A. Vicino, Politecnico di Torino, Italy)
"Computation of optimal algorithms for polynomial
solution and information operators"
10:20-10:40 M. Kowalski, University of Warsaw, Poland
"On approximation of band-limited signals"
10:40-11:00 U. Vazirani, University of California, Berkeley
"X(G**2)and approximations for chromatic number"
11:00-11:20 Coffee
11:20-11:40 M. Shub, T.J. Watson Research Center, IBM
"Machines for the solution of systems of polynomial equations"
11:40-12:00 E. Kalai, Northwestern University
"Complexity in game theory"
12:00-12:20 M. Kon, Boston University
(with E. Novak, University of Erlangen, West Germany)
"On the adaptive and continuous information problems"
12:20-12:40 E. Novak, University of Erlangen, West Germany
"Average case results for zero finding"
12:40- 2:00 Lunch
2:00- 2:20 P. Tiwari, T.J. Watson Research Center, IBM
(with M. Ben-Or, Hebrew University)
"Simple algorithms for approximating all roots
of a polynomial that has only real roots"
2:20- 2:40 A. Sukharev, Moscow State University, U.S.S.R.
"On adaptive and nonadaptive stochastic algorithms
for optimization and approximation"
2:40- 3:00 J. Renegar, Cornell University
"On the complexity of algebraic non-linear programming"
3:00- 3:20 A. Bojanczyk, Cornell University
"Some complexity results in parallel numerical
matrix-based computation"
∂03-Mar-89 1333 @polya.Stanford.EDU:hayes@arisia.xerox.com CSD Retreat
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Mar 89 13:32:58 PST
Received: from arisia.Xerox.COM by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA20510; Fri, 3 Mar 89 13:30:23 -0800
Received: by arisia.Xerox.COM
(5.59++/IDA-1.2.6) id AA03143; Fri, 3 Mar 89 13:29:22 PST
Date: Fri, 3 Mar 89 13:29:22 PST
From: Pat Hayes <hayes@arisia.xerox.com>
Message-Id: <8903032129.AA03143@arisia.Xerox.COM>
To: chandler@polya.stanford.edu
Cc: retreat@polya.Stanford.EDU
In-Reply-To: "Joyce R. Chandler"'s message of Fri, 3 Mar 89 11:24:44 PST <CMM.0.87.604956284.chandler@polya.stanford.edu>
Subject: CSD Retreat
Thanks for the reminder. Unfortunately I will be out of town that
weekend, at a workshop in Florida, so I cant come.
Pat
∂03-Mar-89 1427 X3J13-mailer Re: Issue: ERROR-TERMINOLOGY
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 3 Mar 89 14:27:24 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA19379; Fri, 3 Mar 89 14:27:47 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA21544; Fri, 3 Mar 89 14:23:46 PST
Received: by clam.sun.com (4.0/SMI-4.0)
id AA26314; Fri, 3 Mar 89 14:27:06 PST
Date: Fri, 3 Mar 89 14:27:06 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903032227.AA26314@clam.sun.com>
To: rpg@lucid.com, x3j13@sail.stanford.edu
Subject: Re: Issue: ERROR-TERMINOLOGY
The terminology "CONSEQUENCES ARE UNSPECIFIED" is still a
trap in my opinion. The example, ``the consequences of the
garbage collector when invoked are unspecified'', is not
as appropriate as it might be, because there is no explicit
way to invoke the garbage collector in Common Lisp and the
example is not taken from the specification of the language
as far as I know.
But, what the heck, let's look at this example. Are the
results and effects of this situation "unpredictable but
harmless"? Not in my book. Running the garbage collector
is supposed to have (essentially) *no* visible effects.
It can't change the value of any variable or data structure
in any observable way. It can issue messages, I guess, and
change the report from "ROOM", but that is likely to change
with every call anyway.
Let's pick a few actual examples where the language definition is
proposed to say "consequences are unspecified". (Go ahead, I challenge
you.) I think we will find that the description will have to be more
specific than that. It can make sense to say that "effect X may or may
not occur". It can make sense to say that "data structure Y may be
modified arbitrarily". If we can define a set of effects that we
consider harmless, and change "unpredictable but harmless" to just
"harmless", or some such, that could also make sense, but not the current
language.
∂03-Mar-89 1539 X3J13-mailer What is a FUNCTION?
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Mar 89 15:39:21 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA07284; Fri, 3 Mar 89 16:37:18 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA04478; Fri, 3 Mar 89 16:37:16 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903032337.AA04478@defun.utah.edu>
Date: Fri, 3 Mar 89 16:37:14 MST
Subject: What is a FUNCTION?
To: x3j13@sail.stanford.edu
From section 2.2 of the working draft:
A FUNCTION may be supplied as an argument without error to FUNCALL or
APPLY, and is to be executed as code when arguments are supplied. The
functional computation produces one or more values, produces no
values, or takes a non-local exit.
Is this *really* the best definition of what a FUNCTION is that we can
come up with? I've talked to some other people here and while we are
all having a remarkably hard time coming up with some specific words,
we are all agreed that this definition really misses the boat.
Surprisingly, none of the Lisp texts I have handy have much discussion
on what a function is, and the R**3 Scheme report says almost nothing
about what a procedure object is either. I really had no idea that
there was such a gaping hole in our understanding of such an
apparently fundamental concept....
To me, it seems like the definition of the FUNCTION type ought to
incorporate at least the following four notions:
- encapsulation of process as object
- capture of lexical environment
- generalization via parameters
- evaluation of body delayed until funcall
Also I would expect to see a statement that FUNCTION objects are
created by the evaluation of a (FUNCTION (LAMBDA ...)) form.
Would anybody like to take a stab at putting together a better
definition?
-Sandra
-------
∂03-Mar-89 1548 X3J13-mailer Error Terminology
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 3 Mar 89 15:48:06 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00688g; Fri, 3 Mar 89 15:41:25 PST
Received: by challenger id AA21289g; Fri, 3 Mar 89 15:36:54 PST
Date: Fri, 3 Mar 89 15:36:54 PST
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8903032336.AA21289@challenger>
To: x3j13@sail.stanford.edu
Subject: Error Terminology
Ok Cris, here is the example. It is from CLOS chapter 1.
The description is of the system-supplied method for
SHARED-INITIALIZE. The second argument specifies a list of
slots that will be dealt with in certain cases.
``There is a system-supplied primary method for {\bf
shared-initialize} whose first parameter specializer is the class {\bf
standard-object}. This method behaves as follows on each slot,
whether shared or local:
...
\item{\bull} Any slots indicated by the second argument that are still
unbound at this point are initialized according to their {\bf
:initform} forms. For any such slot that has an {\bf :initform} form,
that form is evaluated in the lexical environment of its defining {\bf
defclass} form and the result is stored into the slot. For example,
if a {\bf :before} method stores a value in the slot, the {\bf
:initform} form will not be used to supply a value for the slot. If
the second argument specifies a name that does not correspond to any
slots accessible in the instance, the results are unspecified.''
Now, should this say that if the second argument specifies a name that
does not correspond to an accessible slot that it is ignored? Well,
that is what it does in some sense, but there may be processing that
goes on to discover the fact that it should be ignored, so supplying
exactly exactly one slot that appears nowhere in the hierarchy might
take an arbitrary amount of time to discover. For example, if there
are 100,000 classes, the CPL might need to be calculated, which could
take up to 40 seconds and involve CONSing 5mbytes, possibly
side-effecting each class object in certain ways. Or while the
programmer is getting coffee, the multitasking system might have
noticed inactivity and woken up the CPL calculation process, computing
the CPL for the right classes, so when the programmer returns and
causes shared-initialize to happen, this effect doesn't happen. Or
the search for the slot might invoke other internal initialization
procedures or protocols that should be harmless. Or maybe some
programming environment structures are altered. Or maybe some other
processes are started.
Right now I don't know even what the odd effects of the CPL
computation will be in any particular Common Lisp, and the CPL
computation might be involved in the effects of shared-initialize.
I wasn't sure what Cris meant by this argument regarding the garbage
collector:
``But, what the heck, let's look at this example. Are the
results and effects of this situation "unpredictable but
harmless"? Not in my book. Running the garbage collector
is supposed to have (essentially) *no* visible effects.
It can't change the value of any variable or data structure
in any observable way. It can issue messages, I guess, and
change the report from "ROOM", but that is likely to change
with every call anyway.''
I might point out that rehashing can happen as a result of GC, and in
parallel processing extensions to Common Lisp, running processes (such
as those behind futures) could be killed. Output in output buffers
might be shipped to their final destinations. Weak pointer arrays
could be altered. Dispatch tables for generic functions could be
recalculated, and instances whose structure had been redefined by
forward-referencing could be re-optimized, and possibly some metaobject
protocol could be triggered.
But, ignoring these, it sounds offhand like he wasn't sure what
effects GC might have or whether they would happen (``essentially'';
``I guess''), but he was certain there would be no visible effects.
Maybe he thought the results were unpredictable but harmless?
Cris suggests:
``If we can define a set of effects that we consider harmless, and
change "unpredictable but harmless" to just "harmless"....''
My point is that it is very hard to enumerate or classify all possible
effects in all possible implementations with all possible legal
extensions on all possible hardware at all future times. And it is
much easier to define terminology that captures our intent and use it.
-rpg-
∂03-Mar-89 1632 X3J13-mailer Re: Issue: ERROR-TERMINOLOGY
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Mar 89 16:32:40 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA09474; Fri, 3 Mar 89 17:30:36 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA04518; Fri, 3 Mar 89 17:30:34 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903040030.AA04518@defun.utah.edu>
Date: Fri, 3 Mar 89 17:30:32 MST
Subject: Re: Issue: ERROR-TERMINOLOGY
To: rpg@lucid.com
Cc: x3j13@sail.stanford.edu
I've been bothered by "the consequences are unspecified" too, although
I've kept my mouth shut on the issue up until now in the hopes that
the problem would resolve itself.
First some background. We've had problems deciding on error
terminology for some of the compiler issues because it seems like none
of the standard error terms really say what we want, which is
something to the effect of: You can't depend on being able to compile
code that does this. In any particular implementation, the behavior
will be well-defined, but that behavior may be (for the compiler
and/or loader) to signal an error. Conforming programs cannot rely on
any particular behavior in this situation, but simply compiling code
that does this will not cause a crash-and-burn situation.
Saying "the consequences are undefined" doesn't seem like the right
thing, because it permits the possibility of random crash-and-burn
errors. I am not sure if "the consequences are unspecified" is really
right either, because I'm not sure if "harmless" was intended to
include signalling an error.
So far, in situations where it is reasonable to signal an error (for
example, issue COMPILE-FILE-SYMBOL-HANDLING), I have been using
"unspecified" but explicitly saying that it is OK to signal an error.
I would feel more confortable with this if the definition of the term
"unspecified" said that signalling errors or warnings is permissible,
at least in those situations where the standard explicitly says it is.
A further problem with "the consequences are unspecified" is that I
think the word "consequences" is too unspecific about is being left
unspecified. :-) We ought to be very careful about using this phrase
and instead try to state exactly which "consequences" are unspecified.
-Sandra
-------
∂03-Mar-89 1704 X3J13-mailer Issue: ERROR-TERMINOLOGY
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 3 Mar 89 17:03:58 PST
Received: from pitney-bowes ([192.9.200.50]) by heavens-gate.lucid.com id AA00803g; Fri, 3 Mar 89 16:57:17 PST
Received: by pitney-bowes id AA11422g; Fri, 3 Mar 89 16:55:51 PST
Date: Fri, 3 Mar 89 16:55:51 PST
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8903040055.AA11422@pitney-bowes>
To: sandra%defun@cs.utah.edu
Cc: rpg@lucid.com, x3j13@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Fri, 3 Mar 89 17:30:32 MST <8903040030.AA04518@defun.utah.edu>
Subject: Issue: ERROR-TERMINOLOGY
Why can't we use phrases like:
"the consequences might be fatal"
"the consequences might signal an error"
"the consequences won't signal an error"
For me, saying "the consequences are undefined" is a bit like saying
"slow, construction ahead" when in fact the bridge might be out.
jlm
∂04-Mar-89 1159 X3J13-mailer Error Terminology
To: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
The error terminology is useful for explaining general behavior
in various situations where we do not wish to state explicitly what could
happen, but ordinary English description is not forbidden.
That is, if you want to say that something is unspecified but might
signal an error, we don't need special terminology for that since that
phrase itself is perfectly fine. (Note: ``unspecified'' allows implementations
to specify what happens, and signalling an error is a fine specification.)
In addition, if people feel that we should elaborate on the possible
consequences of some action, we should simply spell them out. The fact we
have error terminology doesn't mean that we cannot use our judgement in
particular situations.
-rpg-
∂05-Mar-89 1521 hoffman@csli.Stanford.EDU the Symbolic Systems Forum, March 10th.
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Mar 89 15:21:50 PST
Received: by csli.Stanford.EDU (4.0/inc-1.0)
id AA08839; Sun, 5 Mar 89 15:10:39 PST
Date: Sun 5 Mar 89 15:10:38-PST
From: Reid Hoffman <HOFFMAN@CSLI.Stanford.EDU>
Subject: the Symbolic Systems Forum, March 10th.
To: ForumFriends@csli.Stanford.EDU
Message-Id: <605142638.0.HOFFMAN@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
The Symbolic Systems Forum Presents
Dr. Ruben Kleiman
(Apple Intelligent Agents Group)
on
Ontology and Computers
This talk will be about Artificial Intelligence and
Knowledge Representation, focusing on how to encode
knowledge into a computer. On one hand, Winograd, Flores,
and Putnam have advocated a phenomenological view which
abandons the standard mentalist position. On the other hand, there
are also many people (Hayes, McCarthy, Dennett, and most
AI workers) who keep the mentalist position. This talk
will attempt to explicate a perspective which will
reconcile these two philosophical positions.
NOTE: this abstract was briefly communicated over the phone. A more
explicit one may be sent out around Monday or Tues. Also, this will be
the last Symbolic Systems Forum of the quarter. Next quarter`s schedule
will be posted over Spring Break.
Time: 3:15
Place: building 60, room 62n.
The talk is open to the general public and refreshments will be served.
-------
∂06-Mar-89 0838 TAJNAI@Score.Stanford.EDU nominations are closed
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Mar 89 08:38:46 PST
Date: Mon 6 Mar 89 08:33:36-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: nominations are closed
To: faculty@Score.Stanford.EDU
Message-ID: <12475875982.16.TAJNAI@Score.Stanford.EDU>
Nominations are closed for the IBM fellowship. We will make a
decision by tomorrow.
Carolyn Tajnai
-------
∂06-Mar-89 0849 @Score.Stanford.EDU:chandler@polya.Stanford.EDU 3-7 Faculty Lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Mar 89 08:49:34 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 6 Mar 89 08:45:24-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA09349; Mon, 6 Mar 89 07:46:19 -0800
Date: Mon, 6 Mar 1989 7:46:15 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, bureaucrats@score, staff-rep@score
Cc: leventhal@sierra, ct.dnf@forsythe, rosenberg%hplsr@hplabs.hp.com,
chandler@polya.Stanford.EDU
Subject: 3-7 Faculty Lunch
Message-Id: <CMM.0.87.605202375.chandler@polya.stanford.edu>
Just a reminder of tomorrow's faculty lunch - 12:15 in Margaret Jacks Hall,
Room 146. Our guests will be Steven Rosenberg and Frank Carruba from H-P to
talk about "science centers".
∂06-Mar-89 1004 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: Cryptography textbook
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Mar 89 10:04:45 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA15225; Mon, 6 Mar 89 10:02:27 -0800
Message-Id: <8903061802.AA15225@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Mon, 6 Mar 89 10:02:47 PST
Received: by BYUADMIN (Mailer R2.01A) id 5428; Mon, 06 Mar 89 11:01:26 MST
Date: Mon, 6 Mar 89 11:56:24 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Alan Sherman <ats@cs.tufts.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Alan Sherman <ats@cs.tufts.edu>
Subject: Re: Cryptography textbook
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
Diffie and Hellman's survey article ``Privacy and Authentication:
An Introduction to Cryptography'' (Proc. IEEE, March 79) is
a good place to start. There is no great textbook available;
two of the better ones are Cipher Systems by Beker and Piper
and Cryptography and Data Security by Denning. The collection
``Tutorial: The Security of data in Networks'' by D. Davies
has several nice papers.
∂06-Mar-89 1008 STAGER@Score.Stanford.EDU Spring TA Appoitments
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Mar 89 10:08:52 PST
Date: Mon 6 Mar 89 10:04:53-PST
From: Claire Stager <STAGER@Score.Stanford.EDU>
Subject: Spring TA Appoitments
To: faculty@Score.Stanford.EDU
cc: stager@Score.Stanford.EDU, jimenez@Score.Stanford.EDU
Office: CS-TAC 29, 723-6094
Message-ID: <12475892600.9.STAGER@Score.Stanford.EDU>
We are currently accepting TA applications for Spring Quarter from interested
students, and this Thursday or Friday will run lists of applicants
and forward them to course instructors. If you would like to interview
any (or all) of the applicants for your course, please take a moment now
to set up a few office hours during Dead Week (March 12-19) for this purpose.
Inform us by NOON, FRIDAY MARCH 10, of the days, times, office location, and
phone number where you will be available, and we will forward this information
to potential TAs.
At the conclusion of your interviews, send your preferences on to Roy Jones
(Jones@Score) and Claire Stager (Stager@Score). Your preferences will be
taken into consideration, as will the preferences of our student applicants,
when TA appointments are being made. We'll then make every effort to inform
you of who has been assigned to your course as soon as the appointment
process has been completed.
Let me know if you have any questions about the appointment process.
Thanks again.
Claire
-------
∂06-Mar-89 1038 edith@polya.Stanford.EDU faculty candidate visit
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Mar 89 10:38:18 PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA17186; Mon, 6 Mar 89 10:35:40 -0800
Date: Mon, 6 Mar 1989 10:35:38 PST
Sender: Edith Cohen <edith@polya.stanford.edu>
From: Edith Cohen <edith@polya.stanford.edu>
To: thcom@sail, csd@score, aflb-all@polya
Subject: faculty candidate visit
Message-Id: <CMM.0.87.605212539.edith@polya.stanford.edu>
To: thcom@sail, csd@score, aflb-all@polya
Subject: Theory Faculty Candidate
Baruch Schieber (currently IBM T.J. Watson) will be visiting on Thursday,
March 9.
Please send me a message if you want to talk with him, and/or join him
for lunch/dinner.
His schedule so far:
Th 12:30 AFLB talk
1:30 Lunch (after AFLB)
∂06-Mar-89 1114 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Bar-Ilan Symposium on Foudations of Artificial Intelligence --
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Mar 89 11:14:30 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA20198; Mon, 6 Mar 89 11:12:11 -0800
Message-Id: <8903061912.AA20198@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Mon, 6 Mar 89 11:12:28 PST
Received: by BYUADMIN (Mailer R2.01A) id 6882; Mon, 06 Mar 89 12:09:19 MST
Date: Mon, 6 Mar 89 11:59:20 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Martin Charles Golumbic <GOLUMBIC%ISRAEARN.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Martin Charles Golumbic <GOLUMBIC%ISRAEARN.BITNET@forsythe.stanford.edu>
Subject: Bar-Ilan Symposium on Foudations of Artificial Intelligence --
Second A
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
*** Second Announcement ***
Bar-Ilan Symposium on the
Foundations of Artificial Intelligence
19-21 June 1989
Sponsored by the Research Institute for the Mathematical Sciences
Bar-Ilan University, Ramat Gan, Israel
Invited speakers:
John McCarthy (Stanford University)
"Formalized Common Sense Knowledge and Reasoning"
Ronald Rivest (M.I.T.)
"Recent Developments in Machine Learning Theory"
Joseph Halpern (IBM Research)
"Reasoning about Knowledge and Probability"
...............................................................
The Annals of Mathematics and Artificial Intelligence will publish a
special issue, containing selected refereed full length papers, as a
permanent record of the Symposium. These should be submitted shortly
after the conclusion of the Symposium and be at the standard of the
best professional journals.
High quality research papers are solicited for consideration by the
program committee to be presented at the Symposium. Submission of
extended abstracts should be sent by 31 March 1989 in triplicate to:
Prof. Martin Golumbic
BISFAI-89 Program Chair
IBM Israel Scientific Center
Technion City
Haifa, Israel
or by electronic mail to: golumbic@israearn.bitnet
Decisions on talks will be made within one month of receipt.
...............................................................
The Bar-Ilan Symposium on the Foundations of Artificial Intelligence is
intended to become a biennial event which will focus on a range of
topics of concern to scholars applying quantitative, combinatorial,
logical, algebraic and algorithmic methods to AI areas as diverse as
decision support, automatic reasoning, knowledge-based systems, machine
learning, computer vision, and robotics. These include applied
logicians, algorithms and complexity researchers, AI theorists, and
applications specialists using mathematical methods. By sponsoring such
symposia, we hope to influence the spawning of new areas of applied
mathematics and the strengthening of the scientific underpinnings of
artificial intelligence.
........... REGISTRATION AND HOTEL ACCOMODATIONS ........
We have reserved a block of hotel accommodations at the
Kfar Hamaccabia Hotel in Ramat Gan, a first-class hotel which also
has sports facilities available gratis for the Symposium participants.
The Symposium will take place at the University, which is a short ride,
or a half-hour walk, from the hotel. The room rate is $44 single or
$54 double (including breakfast). Reservations must be made DIRECTLY
WITH THE AGENT
Sharon Tours, Attn: Ms. Dennis, P.O.Box 2605, Ramat Gan, Israel
Tel: 972-3-738144 FAX: 972-3-724365
mentioning the Bar-Ilan Symposium.
To allow the organizers to reserve sufficient lecture room space,
please fill in and return this portion of the form to
Dr. Ariel Frank, BISFAI-89 Organizing Chair
Department of Mathematics and Computer Science
Bar-Ilan University, Ramat Gan, ISRAEL
(email: ariel@bimacs.bitnet)
________________________________________________________________
****** PLEASE RETURN THIS FORM *********
Name: ________________________________________________________
Affiliation: _________________________________________________
Address: _____________________________________________________
Electronic mail: ____________________________________________
_____ I will attend the Bar-Ilan Symposium June 19-21, 1989
_____ Please send me the third announcement in May 1989.
I do / do not plan to submit a paper.
∂06-Mar-89 1124 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Crypto '89 -- Final Call for Papers
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Mar 89 11:24:41 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA20810; Mon, 6 Mar 89 11:22:20 -0800
Message-Id: <8903061922.AA20810@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Mon, 6 Mar 89 11:22:26 PST
Received: by BYUADMIN (Mailer R2.01A) id 7165; Mon, 06 Mar 89 12:15:39 MST
Date: Mon, 6 Mar 89 12:10:10 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Kevin S. McCurley" <MCCURLEY%ALMVMA.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Kevin S. McCurley" <MCCURLEY%ALMVMA.BITNET@forsythe.stanford.edu>
Subject: Crypto '89 -- Final Call for Papers
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
CRYPTO '89
FINAL CALL FOR PAPERS
This is the FINAL call for papers for the IACR conference CRYPTO '89.
If you intend to submit a paper, please read carefully the instructions
below. In particular, let me emphasize that the STRICT deadline is
March 17. By that time, I must have your submission(s) ON MY DESK.
For more detail, read the instructions below. If you must use a private
courier (Federal Express or the like), please use the following address,
NOT the one in the call for papers:
Gilles Brassard
Crypto '89 Program Chairperson
Departement IRO (computer science)
Pavillon principal, V-240
Universite de Montreal
2900 Edouard-Montpetit
Montreal, Quebec
Canada H3C 3J7
telephone: (514)343-6807
Please take account of the cover page for facilitating blind refereeing
and of the length limit on submissions (although there is no limit on the
length of a clearly marked appendix). If you have questions, it is best
to ask them via electronic mail.
I am looking forward to receiving your best work.
--------------------------------------------------------------------
CRYPTO '89
CALL FOR PAPERS
The Ninth Annual Crypto Conference sponsored by the International
Association for Cryptologic Research (IACR) in cooperation with the
IEEE Computer Society Technical Committee on Security and Privacy, and
the Computer Science Department of the University of California, Santa
Barbara, will be held on the campus of the University of California,
Santa Barbara, on August 20-24, 1989. Original research papers and
technical expository talks are solicited on all practical and
theoretical aspects of cryptology. It is anticipated that some talks
may also be presented by special invitation of the Program Committee.
In particular, I am very pleased to announce that David Kahn has
accepted to give an invited talk.
INSTRUCTIONS FOR AUTHORS: Authors are requested to send ten copies of
a detailed abstract (not a full paper) by March 17, 1989, to the
Program Chairperson at the address given below. Abstracts should
contain sufficient detail, as well as references to and comparisons
with relevant extant work, to enable Program Committee members to
appreciate their merits. It is recommended that abstracts start with a
succinct statement of the problem and discussion of its significance
and relevance to cryptology, appropriate for a non-specialist reader.
In order to facilitate blind refereeing, the names of authors and
their affiliations should only appear on the cover page of the paper;
it should be possible to remove this page and send the papers to
Program Committee members. Limits of 10 double-spaced pages and 2500
words (not counting the bibliography and the cover page) are placed on
all abstracts. If the authors believe that more details are essential
to substantiate the main claims of the paper, they are asked to
include a clearly marked appendix that will be read at the discretion
of the Program Committee. Abstracts that significantly deviate from
these guidelines risk rejection without consideration of their merits.
Abstracts received after the March 17 deadline WILL NOT BE
CONSIDERED, unless they are postmarked not later than March 13 and
arrive a reasonable time thereafter. Authors will be informed of
acceptance or rejection in a letter mailed not later than May 26.
A compilation of all abstracts accepted will be available at the
conference. Authors of accepted papers will be given until July 14,
1989 to submit revised abstracts for this compilation. Complete
conference proceedings will be published in Springer-Verlag's Lecture
Notes in Computer Science series at a later date. The Program
Committee will consider abstracts that have also been submitted to
other conferences. However, if a submission is accepted for
presentation at more than one conference, the authors may present the
results more than once, but may publish them in at most one
proceedings.
The Program Committee consists of
Josh Benaloh (University of Toronto)
Russell Brand (Special session chairperson, Lawrence Livermore Laboratory)
Gilles Brassard (Committee chairperson, Universite de Montreal)
Claude Crepeau (Massachusetts Institute of Technology)
Whitfield Diffie (Bell Northern Research)
Joan Feigenbaum (AT&T Bell Laboratories)
James Massey (ETH Zentrum, Zurich)
Jim Omura (Cylink Corporation)
Gustavus Simmons (Sandia National Laboratories)
Scott Vanstone (University of Waterloo)
Send abstracts to the For other information,
program chairperson: contact the general chairman:
---------------------------- ---------------------------
Gilles Brassard, Crypto '89 Kevin McCurley
Departement IRO IBM Research, K53/802
Universite de Montreal 650 Harry Road
C.P. 6128, Succursale ``A'' San Jose, CA 95120-6099
Montreal (Quebec) U.S.A.
CANADA H3C 3J7 telephone: (408) 927-1708
telephone: (514) 343-6807 Internet: mccurley@ibm.com
email: brassard@iro.umontreal.ca Bitnet: mccurley@almvma
DO NOT USE THIS ADDRESS WITH
PRIVATE COURIER -- SEE ABOVE
-------------------------------------------------------------------------
∂06-Mar-89 1130 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Re: Cryptography textbook
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Mar 89 11:29:55 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA21439; Mon, 6 Mar 89 11:27:14 -0800
Message-Id: <8903061927.AA21439@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Mon, 6 Mar 89 11:25:38 PST
Received: by BYUADMIN (Mailer R2.01A) id 7285; Mon, 06 Mar 89 12:16:39 MST
Date: Mon, 6 Mar 89 12:31:03 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Lawrie Brown <munnari!cs.adfa.oz.au!lpb@UUNET.UU.NET>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Lawrie Brown <munnari!cs.adfa.oz.au!lpb@UUNET.UU.NET>
Subject: Re: Cryptography textbook
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
beigel@CRABCAKE.CS.JHU.EDU:
> Can anyone recommend a textbook for a senior/1st-year-grad level
> course on cryptography?
The following book has just been published by Prentice-Hall
Australia, US & Europe:
Cryptography: An Introduction to Computer Security
by J. Sebbery & J. Pieprzyk. Prentice-Hall 1989.
To help you gauge your interest in the book, appended below are the
cataloging details and the Table of Contents.
----------------------------------------------------------------
Library of Congress
Cataloguing-in-Publication Data
----------------------------------------------------------------
Seberry, Jennifer, 1944-
Cryptography: an introduction to computer security/by Jennifer
Seberry and Josef Pieprzyk.
p. cm
Bibliography:p.
ISBN 0-13-194986-1
1. Computers - Access control. 2. Cryptography.
I. Pieprzyk, Josef, 1949- .II. Title.
QA76.9.A25S37 1988
005.8 - dc19 87-27026
CIP
----------------------------------------------------------------
CONTENTS
========
Preface
Chapter 1. Introduction
Chapter 2. Background theory
2.1 Mathematical methods
2.2 Complexity theory
2.3 Complexity of selected problems used in cryptology
2.4 Information theory
Chapter 3. Encryption methods of information protection
3.1 Classical ciphers
3.2 Symmetric algorithms and DES
3.3 Asymmetric algorithms or public key cryptosystems
Chapter 4. Authentication methods
4.1 Elementary methods of message authentication
4.2 Subliminal channel
4.3 Digital signatures
4.4 Other authentication techniques
4.5 Summary
Chapter 5. Cryptography in computer network security
5.1 Information protection in computer networks
5.2 Key management issues
5.3 Electronic funds transfer (EFT)
5.4 Summary
Chapter 6. Application of cryptography in databases
6.1 Database model
6.2 Crytographic transformation preserving data structure
6.3 Application of cryptography to protection of information
during processing
6.4 Privacy homomorphisms
6.5 Summary
Chapter 7. Other cryptographic techniques
7.1 Linear feedback shift registers
7.2 One-way ciphers and passwords
7.3 Smart cards and information cards
7.4 Unforgeable ID cards using smart cards
7.5 Summary
Chapter 8. Security in operating systems
8.1 Access control in computer systems
8.2 Implementations of access control systems
8.3 Rationale for security evaluation classes
8.4 Summary
Chapter 9. Minimum knowledge systems
9.1 An introduction to the minimum knowledge concept
9.2 More on the Fiat-Shamir smart card protocol
9.3 Subliminal free verification using minimum knowledge
protocols
9.4 Conclusion
Appendix A
A.1 Frequencies of occurrences of characters in languages
A.2 Frequencies of occurrences of pairs of letters in languages
Appendix B
B.1 DES code
B.2 Key representation for DES
Appendix C
Vigenere, Beauford or Variant Beauford code
Bibliography
Index
------------------------------------------------------------
Apparently Prentice-Hall US, have had problems obtaining this book.
It IS OUT, and Prentice-Hall Australia have substantial stocks of it.
So if you have problems obtaining it from Prentice-Hall US, contact:
The Marketing Dept.
Prentice Hall Australia
PO Box 151
Brookvale. NSW 2100
Australia
Phone: +61 2 938 1830
Fax: +61 2 938 6826
Regards
Lawrie Brown.
∂06-Mar-89 1133 X3J13-mailer Re: KMP's personal comments on 22-Feb-89 Character Proposal
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 6 Mar 89 11:32:45 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa02296; 6 Mar 89 18:55 GMT
Date: Mon, 6 Mar 89 19:22:51 GMT
Message-Id: <19790.8903061922@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: KMP's personal comments on 22-Feb-89 Character Proposal
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>, Baggins@ibm.com
In-Reply-To: Kent M Pitman's message of Fri, 3 Mar 89 15:17 EST
Cc: X3J13@sail.stanford.edu
> - Is $ really what is replaced by the British pound sign on British
> displays? I had always thought that # was what was replaced.
It is often the case that hash is replaced by the british pound sign.
For example, I soon learned to recognize L'(lambda ...). Indeed,
ASCII-based systems (machines, terminals, etc) seem to do this,
though some other things (ICL 1900 series machines, say) may replace
dollar sign with pound.
-- Jeff
∂06-Mar-89 1322 X3J13-mailer Re: minor comments on letter ballot material
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 89 13:22:47 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 551534; Mon 6-Mar-89 16:19:23 EST
Date: Mon, 6 Mar 89 16:18 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: minor comments on letter ballot material
To: Gregor.pa@Xerox.COM, chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@SAIL.STANFORD.EDU, skona%csilvax@hub.ucsb.edu
In-Reply-To: <19890302024559.5.GREGOR@SPIFF.parc.xerox.com>
Message-ID: <19890306211857.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Wed, 1 Mar 89 18:45 PST
From: Gregor.pa@Xerox.COM
Date: Wed, 1 Mar 89 18:22 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Here's a suggestion from one of our CLOS implementors. Would this
change (adding the word "affected") require a vote?
Page 2-9 Redefining Classes
Updating such an instance occurs at an implementation-dependent time,
but no later than the next time a slot of that instance is read or written.
I think I'd prefer if this said:
Updating such an instance occurs at an implementation-dependent time,
but no later than the next time an affected slot of that instance is
read or written.
I (Moon again) think this is a good idea.
This change makes it impossible for people to use MAKE-INSTANCES-OBSOLETE
to arrange for any future access to the slots of an instance to trap.
One of the reasons we gave for not adding an instance enumeration
mechanism was the availability of this functionality. So, I don't think
we should make this change.
We could say that MAKE-INSTANCES-OBSOLETE "affects" all the slots, rather
than saying that it "affects" none of the slots. However, I'm willing to
just drop the issue.
∂06-Mar-89 1348 X3J13-mailer Feb. 21 Letter Ballot: editorial issues
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 89 13:48:15 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 551584; Mon 6-Mar-89 16:45:08 EST
Date: Mon, 6 Mar 89 16:44 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Feb. 21 Letter Ballot: editorial issues
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: <8902211607.AA09708@decwrl.dec.com>
Message-ID: <19890306214441.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
This is the official response of Symbolics to the Feb 21 1989
letter ballot on Common Lisp editorial issues.
________________________________________________________________________
Issue or section name | Version | Y | I | A |
------------------------------------------------------------------------
CUT-OFF-DATES | 4 | Y | | |
------------------------------------------------------------------------
ERROR-TERMINOLOGY | 5 | | I | |
------------------------------------------------------------------------
FONTS | 2 | Y | | |
------------------------------------------------------------------------
TOC | 1 | Y | | |
------------------------------------------------------------------------
Section 1.8 | 5.8 | | I | |
------------------------------------------------------------------------
Section 2.3 | 5.8 | | I | |
------------------------------------------------------------------------
Section 2.4 | 5.8 | | I | |
------------------------------------------------------------------------
Section 2.5 | 5.8 | | I | |
------------------------------------------------------------------------
Section 6.1 | 5.8 | | I | |
------------------------------------------------------------------------
Accompanying comments:
ERROR-TERMINOLOGY: The version included with the ballot is inadequate
(details criticisms in comments mailed earlier from Moon and from Pitman).
The more recent draft mailed out by Gabriel is better. We intend to
vote yes when we see a draft that is precise, self-consistent, and
doesn't contain examples that contradict the rest of the definition of
Common Lisp; we believe the most recently mailed draft is quite close to
that and would be surprised not to see an acceptable draft at the March
meeting.
The five numbered sections: We approve these in principle, but aren't
ready to cast them in concrete. We haven't had time to review them with
the extreme care warranted for a language standard, and don't know who
else, if anyone, has reviewed them that thoroughly. We intend to vote
yes when we know that these have been reviewed with good judgement and
attention to detail, or if informed that voting yes does not mean that
these sections will be put into the standard without permitting an
opportunity for further review and correction.
∂06-Mar-89 1355 X3J13-mailer minor comments on letter ballot material
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 6 Mar 89 13:55:10 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA02303g; Mon, 6 Mar 89 13:46:42 PST
Received: by challenger id AA25811g; Mon, 6 Mar 89 13:41:55 PST
Date: Mon, 6 Mar 89 13:41:55 PST
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8903062141.AA25811@challenger>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: Gregor.pa@Xerox.COM, chapman%aitg.DEC@decwrl.dec.com,
x3j13@SAIL.STANFORD.EDU, skona%csilvax@hub.ucsb.edu
In-Reply-To: David A. Moon's message of Mon, 6 Mar 89 16:18 EST <19890306211857.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: minor comments on letter ballot material
Date: Mon, 6 Mar 89 16:18 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Line-Fold: No
This change makes it impossible for people to use MAKE-INSTANCES-OBSOLETE
to arrange for any future access to the slots of an instance to trap.
One of the reasons we gave for not adding an instance enumeration
mechanism was the availability of this functionality. So, I don't think
we should make this change.
We could say that MAKE-INSTANCES-OBSOLETE "affects" all the slots, rather
than saying that it "affects" none of the slots. However, I'm willing to
just drop the issue.
I think it's hard to do. It is specified that class redefintion will call
make-instances-obsolete. So all the slots would be affected whenever a class
redefinition makes the instances obsolete.
We could do it by changing make-instances-obsolete to take a list of slots to
mark as affected.
Patrick.
∂06-Mar-89 1435 @Score.Stanford.EDU:andy@Gang-of-Four.Stanford.EDU CS student vote on William A. Brown's Statement
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Mar 89 14:35:36 PST
Received: from Gang-of-Four.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 6 Mar 89 14:32:15-PST
Received: by Gang-of-Four.Stanford.EDU (5.59/25-eef) id AA08059; Mon, 6 Mar 89 14:34:50 PST
Date: Mon, 6 Mar 89 14:34:50 PST
From: Andy Freeman <andy@Gang-of-Four.Stanford.EDU>
Message-Id: <8903062234.AA08059@Gang-of-Four.Stanford.EDU>
To: hk.dxk@forsythe, hk.grh@forsythe, s.street@macbeth, gq.vvn@forsythe,
g.gorin@macbeth, hk.ixb@forsythe, hk.jjs@forsythe, hk.rwb@forsythe,
siegman@sierra, cr.apc@forsythe, faculty@score
Subject: CS student vote on William A. Brown's Statement
I received 19 votes from CS students opposing William A. Brown's
statement; no one, not even students in other departments, supported
WAB's statement. (A couple of EE students voted against WAB's
statement, but I did not count their votes.)
I took this vote because I agreed with WAB that his statement should
be given the same respect that Oren's statement was. I am forwarding
the result of the vote to those people who received WAB's statment.
For those of you who care about such things, as near as I can tell,
WAB is not a CS student. (He isn't in CS. I think that MIS students,
who are in an interdisciplinary program adminstered by the Med School,
can be considered CS students, but he isn't in that program either.)
In the middle of last week I asked him to clarify his standing to
speak as a CS student, but he has not bothered to reply.
-andy
∂06-Mar-89 1449 X3J13-mailer Re: cs proposal and straw vote
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 89 14:49:36 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 551645; Mon 6-Mar-89 17:44:45 EST
Date: Mon, 6 Mar 89 17:44 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: cs proposal and straw vote
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>, baggins@ibm.com
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903021757.AA03241@defun.utah.edu>
Message-ID: <19890306224429.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 2 Mar 89 10:57:40 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
....
Why do we need CHAR-CODE-LIMIT, CODE-CHAR, and CHAR-CODE anyway?
While bits and fonts were in the standard, these were useful for
things like creating a character with the same code but different bits
or font attributes, but now that's out. If we want a function to use
for hashing characters, that's what CHAR-INT is for. The only other
use I can think of is supporting iteration over characters, and it
seems like this could be extremely inefficient in implementations that
support user-defined character sets. (In such a case, I would imagine
that one would make CHAR-CODE-LIMIT correspond to the limit imposed by
the representation, perhaps the same as MOST-POSITIVE-FIXNUM, but in
actual practice, very few of those codes would have corresponding
characters.) I agree with Dan that we'd be better off having a
specialized iterator.
You left out the most obvious use, which is associating data of some
sort with characters by making an array indexed by char-code. I agree
that this will not be practical in implementations where CHAR-CODE-LIMIT
is very large.
I didn't really understand Dan's suggestion for a specialized iterator,
since in one paragraph he said it was premature to put in character
registries, then in the next paragraph he said there should be an
iterator that takes a character registry and executes the body for
each character in that registry.
I think that the char-code stuff needs to be retained to ease the writing
of applications that are portable between implementations with different
sets of implementation-defined character attributes. However, I would
probably not object strenuously to the removal of the char-code stuff
(I can't promise; I'd have to check with other Symbolians first) since
it could become an implementation-dependent extension.
Should we consider extending MAKE-STRING-OUTPUT-STREAM to take an
:ELEMENT-TYPE keyword?
That seems like a good idea. WITH-OUTPUT-TO-STRING also. An idea which
I slightly prefer is that WITH-OUTPUT-TO-STRING when no string argument
is provided and MAKE-STRING-OUTPUT-STREAM produce a stream that accepts
all characters and returns a string of some element-type that
accomodates all the characters that were actually output. This reflects
Symbolics current practice.
In fact Symbolics Genera will also widen a base-string provided as a
string argument to WITH-OUTPUT-TO-STRING into a general-string if
necessary. If we wanted to put that into the standard, that would be
great as the user would never have to worry about the element-type,
however if other implementors object I won't push it.
∂06-Mar-89 1453 X3J13-mailer Re: cs proposal comments
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 89 14:53:45 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 551649; Mon 6-Mar-89 17:51:21 EST
Date: Mon, 6 Mar 89 17:51 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: cs proposal comments
To: David N Gray <Gray@DSG.csc.ti.com>, Thom Linden <baggins@IBM.com>
cc: x3j13@sail.stanford.edu
In-Reply-To: <2813859524-5211323@Kelvin>
Message-ID: <19890306225107.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 2 Mar 89 13:38:44 CST
From: David N Gray <Gray@DSG.csc.ti.com>
> >> Never mind that; the real question is why do you want the standard to not
> >> specify the meaning of tabs and form-feeds in source files?
> >>
> I don't have my CLtL with me but I don't think a meaning is given
> to the semi-standard characters (unless we consider them self defining?)
I'm talking about page 336 of CLtL which specifies that the reader treats
#\TAB and #\PAGE as whitespace. Section A.22.1.1 of the February 21 document
specifies deleting the mention of these.
I think I saw several messages complaining about this. I think it would
actually be okay to remove the semi-standard characters, and that this would
not mean that portable programs could not be written with tabs and form-feeds.
It's already the case that when porting a program between implementations one
may have to do character set translation on the source text of the program.
When porting to an implementation that does not have tab or formfeed (which
is already legal), the character set translation must change those into
spaces, or something.
On the other hand, a nice thing about CLtL is the way it said that an
implementation doesn't have to support tabs, but if it does have tabs,
this is how they should work. Thus the programmer can rely on having
only two tab stories to deal with: either tabs work as some amount of
whitespace, or there aren't any tabs at all. Thus it might make sense
to retain these characters with the same semi-standard status. I don't
see how doing that would harm the rest of the characters proposal.
Since it says somewhere that implementations are allowed to support only
a subset of a registry, it would be valid to support only a subset of
the control-characters registry (format-effectors might be a better
name).
∂06-Mar-89 1506 BSCOTT@Score.Stanford.EDU Univ. Travel Task Force
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Mar 89 15:06:31 PST
Date: Mon 6 Mar 89 15:01:52-PST
From: Betty Scott <BSCOTT@Score.Stanford.EDU>
Subject: Univ. Travel Task Force
To: Faculty@Score.Stanford.EDU
cc: BScott@Score.Stanford.EDU
Message-ID: <12475946665.18.BSCOTT@Score.Stanford.EDU>
V.P. Bill Massy has created a University Task Force to evaluate the perform-
ance of American Express over the past four years. The contract expires this
fall. Ken Down is the SOE representative on the Task Force, and has asked
me to gather CS input on the following:
1. Do you use American Express Travel Agency?
2. If you do, please comment on the quality of service you receive from
American Express.
3. How do you rate the quality of Stanford's internal processing of expense
reports and reimbursements?
4. Please list strengths and weaknesses of the current "preferred" (American
Express) agency, corporate charge card and related travel policies.
Your comments will affect the ultimate decision of whether to retain American
Express or to solicit applications from others to become Stanford's pre-
ferred agency. We will appreciate hearing from you by Friday, March 10.
Be assured that anonymity will be maintained.
Thanks very much in advance.
Betty
-------
∂06-Mar-89 1512 BSCOTT@Score.Stanford.EDU American Express
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Mar 89 15:12:04 PST
Date: Mon 6 Mar 89 15:03:11-PST
From: Betty Scott <BSCOTT@Score.Stanford.EDU>
Subject: American Express
To: Faculty@Score.Stanford.EDU
cc: BScott@Score.Stanford.EDU
Message-ID: <12475946905.18.BSCOTT@Score.Stanford.EDU>
Sorry, I forgot. Please send your comments/responses to me.
Thanks,
Betty
-------
∂06-Mar-89 1527 misha@polya.Stanford.EDU AFLB tomorrow!
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Mar 89 15:27:50 PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA10001; Mon, 6 Mar 89 15:24:03 -0800
Date: Mon, 6 Mar 89 15:24:03 -0800
From: Michael Kharitonov <misha@polya.Stanford.EDU>
Message-Id: <8903062324.AA10001@polya.Stanford.EDU>
To: aflb-all@polya.Stanford.EDU
Subject: AFLB tomorrow!
Next AFLB is tomorrow, March 7, at 4:15 in room 352.
Completeness results for two-party cryptographic protocols.
By Mr. Joe Kilian
This paper will survey recent work in proving completeness results for
two-party protocols. Joe will primarily discuss work he has done with
Ben-Or, Crepeau, Goldwasser, Nisan, and Wigderson.
The goal of this research is to develop an understanding of the
cryptographic power of simple protocols, and to apply this knowledge
to remove or weaken cryptographic assumptions. One of the early
results in this area says that if one can implement a simple protocol,
known as oblivious transfer, then one can implement some very general
two-party games. Machinery has also been developed to show
completeness results for other ``protocols,'' such as an ideal noisy
channel. Applications of this research have been applied to the study
of multi-prover interactive proof systems, bounded interaction
zero-knowledge, space-bounded automata, efficient zero-knowledge
protocols for NP, and weakening the cryptographic assumptions necessary
for secure circuit evaluation.
∂06-Mar-89 1538 X3J13-mailer Re: cs proposal and straw vote
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 6 Mar 89 15:37:53 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA12950; Mon, 6 Mar 89 18:35:51 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA15870; Mon, 6 Mar 89 18:33:59 EST
Message-Id: <8903062333.AA15870@mist.>
To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: x3j13@sail.stanford.edu
Subject: Re: cs proposal and straw vote
In-Reply-To: Your message of Mon, 06 Mar 89 17:44:00 -0500.
<19890306224429.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 06 Mar 89 18:33:55 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Date: Mon, 6 Mar 89 17:44 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
I didn't really understand Dan's suggestion for a specialized iterator,
since in one paragraph he said it was premature to put in character
registries, then in the next paragraph he said there should be an
iterator that takes a character registry and executes the body for
each character in that registry.
It's actually very simple. I have doubts about putting registries in
at all, but IF we do decide to put them in there should be a way to
iterate over them.
∂06-Mar-89 1627 X3J13-mailer cs proposal straw vote
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 89 16:27:30 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 551767; Mon 6-Mar-89 19:23:38 EST
Date: Mon, 6 Mar 89 19:23 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: cs proposal straw vote
To: Thom Linden <baggins@IBM.com>
cc: Common Lisp mailing <x3j13@sail.stanford.edu>
In-Reply-To: <890222.120815.baggins@almvma>
Message-ID: <19890307002320.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
This is the official response from Symbolics to the 22 Feb 89
straw vote on the characters proposal.
The format in which this was presented makes it very difficult to
know what we're voting on. Fortunately, it's only a straw poll.
However, you need to be aware that we had to guess what exactly
we're voting on, and so the results of the straw poll might not
be too meaningful, if different participants made different guesses.
I would strongly suggest casting this material into a precise
and unambiguous form before the binding vote occurs. That could
save a great deal of discussion time and minimize the possibility
of perfectly good language features being voted down simply because
of the way they were presented. It's especially important not to
retain the current format, where things are discussed in three places
(the body of the proposal, the appendix, and the ballot) and the
three places contradict each other in significant ways.
Issue: CHAR-FONT-UNUSED-CHAR-BITS-NONPORTABLE
Yes. We will want to check the p.29 rules for implementation-dependent
character attributes carefully.
Issue: CHAR-INT-ONLY-USEFUL-WHEN-ATTRIBUTES-SUPPORTED
No. CHAR-INT is needed for hashing. CHAR-INT should be retained, but
INT-CHAR and its shadow in the COERCE function should be removed.
This issue is unrelated to the apparent primary goal of the proposal.
Issue: CHARACTER-TYPE-RESTRICTIVEC
Define BASE-CHARACTER as a subtype of STRING.
No. Yes to BASE-CHARACTER as a subtype of CHARACTER.
Standard characters are a subset of the base
characters.
Yes.
STANDARD-CHAR type is replaced by (CHARACTER :STANDARD)
No. Keep STANDARD-CHAR. A change here is unnecessary for the rest of
the proposal. Adding (CHARACTER :STANDARD) would be okay, not adding it
would also be okay.
Remove the semi-standard characters.
No. A change here is unnecessary for the rest of the proposal.
Issue: STRING-TYPE-RESTRICTIVE
Define STRING as a union type
Yes
STRING used as a type specifier for object creation
means (VECTOR CHARACTER)
Yes
All string functions operate as specified on any
string object except it is an error to insert
an extended character into a base string.
Yes. This is already required by the requirement on storing
into arrays in general.
Extend the COERCE function to allow coercion from
base string to extended string.
No, this feature is already present in CLtL, since any sequence
type can be coerced to any other sequence type.
Issue: STRING-TYPE-ABBREVIATIONS
Yes.
Issue: SIMPLE-STRING-TYPE-RESTRICTIVE
Define SIMPLE-STRING as a union type
Abstain. We want to understand the consequences of this better,
vis a vis the alternative of defining SIMPLE-STRING as a
particular type, either (AND SIMPLE-ARRAY GENERAL-STRING)
or (AND SIMPLE-ARRAY BASE-STRING).
Define SIMPLE-STRING as a type specifier for object
creation means (SIMPLE-ARRAY CHARACTER (size))
Depends on the outcome of the previous.
Issue: SIMPLE-STRING-TYPE-ABBREVIATIONS
Add SIMPLE-BASE-STRING
Add SIMPLE-GENERAL-STRING
Depends on the outcome of the previous. This is getting to
be too many names.
Issue: FILE-EXTERNAL-REPRESENTATION
Add :EXTERNAL-CODED-CHARACTER-FORMAT keyword to OPEN
Approved in principle, but the name is too long.
Issue: CHAR-CODE-NON-PORTABLE
Add CHAR-CCS-VALUE function
Approved in principle, but the name is too long, uses an unmotivated
abbreviation "ccs", and is not consistent with the name of the OPEN
keyword. Although they don't do exactly the same thing (the OPEN
keyword can specify multiple coded character sets and a protocol
for switching among them), they are related enough that the names
should express their relation.
This issue is unrelated to the apparent primary goal of the proposal.
For both of the above, the main naming problem seems to be to keep
clear the distinction between these and CHAR-CODE. How about
CHAR-EXTERNAL-CODE for the function name and :EXTERNAL-CODE for
the OPEN keyword? These aren't the best names in the world, but
they are an improvement, maybe someone else can think of something
better.
Also this seems to be an incomplete set of facilities. Conversion
of characters to external codes is provided, but not the inverse.
Conversion between internal and external encodings is bundled with
stream I/O, but not available on its own; there could be functions
that convert a string to/from a vector of integers under a specified
"external-coded-character-format".
Issue: STRING-BINARY-WIDTH
Add EXTERNAL-CODED-STRING-LENGTH function
No. The meaning of what this returns is too implementation-dependent
and the need for this has not been shown. If this is retained, the name
should be consistent with the names of the preceding two facilities.
This issue is unrelated to the apparent primary goal of the proposal.
Issue: CHARACTER-IDENTIFICATION-NONPORTABLE
Introduce the concept of Registries
We incline towards yes, except that the relation to ISO work has not
been made clear. In particular, how can registries be used before the
putative ISO committee is formed and completes its work?
Standardize on #\registry:id
Yes, assuming we guessed correctly what this was supposed to mean.
add all-implemented-registries
Add *ALL-CHARACTER-REGISTRY-NAMES* variable
Yes to one, no to the other. The second name is better.
Add FIND-CHAR function
Add CHAR-LABEL function
Add CHAR-REGISTRY-NAME function
Yes to these three.
New syntax for CHARACTER type specifier
New argument to CHARACTERP
No, the need for these has not been shown. Why not
call the CHAR-REGISTRY-NAME function?
New #\label:registry character name syntax
No, contradicts #\registry:id just above.
Is this issue unrelated to the apparent primary goal of the proposal?
That's the big question, isn't it? A more constructive way to put the
question is, how would a program make use of character registries to
access portably characters outside of the 96 characters that all Common
Lisp implementations must have? The proposal appears to be completely
silent on that point. We think we know how character registries would
actually be very useful for that. However, instead of counting on the
reader to guess the usefulness of character registries, the proposal
should contain some examples. If the character committee can't come up
with any examples, then perhaps character registries aren't really
needed.
∂06-Mar-89 1714 X3J13-mailer Review schedule reminder
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 89 17:13:56 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 551816; Mon 6-Mar-89 20:11:10 EST
Date: Mon, 6 Mar 89 20:10 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Review schedule reminder
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: <8902271052.AA15941@decwrl.dec.com>
Message-ID: <19890307011058.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 27 Feb 89 05:31
From: chapman%aitg.DEC@decwrl.dec.com
Please let me know if you have any trouble accessing or reviewing this
information.
I am not equipped to do anything with the tex source files you've been
mailing out. So far I have been unable to open a network connection
to hudson.dec.com to access the dvi file.
∂06-Mar-89 1755 @Score.Stanford.EDU:marty@cis.Stanford.EDU Univ. Travel Task Force
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Mar 89 17:48:31 PST
Received: from cis.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 6 Mar 89 17:44:28-PST
Received: by cis.Stanford.EDU (5.59/inc-1.0)
id AA14078; Mon, 6 Mar 89 17:42:57 PDT
Date: Mon, 6 Mar 89 17:42:57 PDT
From: marty@cis.Stanford.EDU (Marty Tenenbaum)
Message-Id: <8903070142.AA14078@cis.Stanford.EDU>
To: BSCOTT@Score.Stanford.EDU
Cc: Faculty@Score.Stanford.EDU, BScott@Score.Stanford.EDU
In-Reply-To: Betty Scott's message of Mon 6 Mar 89 15:01:52-PST <12475946665.18.BSCOTT@Score.Stanford.EDU>
Subject: Univ. Travel Task Force
Betty, I dont use american express, but I have used Compass Pt. Travel
for years (they are Schlumbergers local official agency) and the
service is impeccable - always the cheapest fares, tickets hand delivered
etc. If you ever are in a position to choose an agency for the CS department,
check them out (owner is Ann Raphael, wife of AI pioneer Bert Raphael;
Schlumberger account manager is Phyllis Schiffman).
JMT.
∂07-Mar-89 0254 X3J13-mailer clarification
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 7 Mar 89 02:54:26 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA06496; Tue, 7 Mar 89 02:52:25 PST
Message-Id: <8903071052.AA06496@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA06496; Tue, 7 Mar 89 02:52:25 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 7 Mar 89 05:47
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: clarification
In Symbolics' vote, Moon mentioned that he wasn't willing to vote on the
sections on the letter ballot because he was afraid they would be cast
in concrete. I should have made it more clear that these sections can
be changed, via clean-up, after they have been voted on.
I am trying to get incremental closure on the standard, just as one would
stop gratuitous changes on software being developed in a large system
a few modules at a time. That never means that the modules originally
"fixed" will not be subject to change if the whole system doesn't work!
Please do not be afraid to spend time reviewing these sections now and
commenting if there are problems. Even if the volume of reading looks
large, imagine how large it will look in a few months when you have
over 1000 pages to review.
Please review and vote!!!
kc
∂07-Mar-89 1011 STAGER@Score.Stanford.EDU Tau Beta Pi
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Mar 89 10:10:58 PST
Date: Tue 7 Mar 89 10:06:41-PST
From: Claire Stager <STAGER@Score.Stanford.EDU>
Subject: Tau Beta Pi
To: instructors@Score.Stanford.EDU
cc: tas@Score.Stanford.EDU, sec@Score.Stanford.EDU, jimenez@Score.Stanford.EDU,
stager@Score.Stanford.EDU
Office: CS-TAC 29, 723-6094
Message-ID: <12476155072.17.STAGER@Score.Stanford.EDU>
Tau Beta Pi survey forms will be sent out to instructors this week. Tina
Jimenez is making up packets of blank forms, instruction sheets, pencils
and return envelopes for each class and will send them out via courier.
****************************************************************************
PLEASE RETURN THE COMPLETED SURVEY FORMS TO TINA JIMENEZ IN CS-TAC BY THE END
OF FINALS WEEK (MARCH 24).
****************************************************************************
Forms should be returned to Tina in the envelopes provided.
Questions can be directed to Tina at 3-0909, or Jimenez@Score.
Thanks.
Claire
-------
∂07-Mar-89 1011 debra@russell.Stanford.EDU REMINDER-EVENING SEMINAR
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Mar 89 10:11:25 PST
Received: from localhost by russell.Stanford.EDU (4.0/inc-1.0)
id AA06191; Tue, 7 Mar 89 10:12:44 PST
Message-Id: <8903071812.AA06191@russell.Stanford.EDU>
To: evesem@russell.Stanford.EDU
Cc: kuder@russell.Stanford.EDU, debra@russell.Stanford.EDU
Subject: REMINDER-EVENING SEMINAR
Date: Tue, 07 Mar 89 10:12:42 PST
From: Debra Alty <debra@russell.Stanford.EDU>
REMINDER
The next EVENING SEMINAR will be Wednesday, March 8th @ 7:30pm in the
CSLI Cordura Conference Room.
Professor Ellen Markman, Psychology Department, will be leading the
discussion.
The following will be served:
Shrimp cocktail Apricot Brandy
Cheese w/crackers Wine
Fresh fruit platter Beer
Baklava Sparkling Waters
Coffee
Tea
Debra
∂07-Mar-89 1126 emma@csli.Stanford.EDU CSLI Calendar correction
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Mar 89 11:26:30 PST
Received: by csli.Stanford.EDU (4.0/inc-1.0)
id AA11664; Tue, 7 Mar 89 10:57:43 PST
Date: Tue, 7 Mar 89 10:57:43 PST
From: emma@csli.Stanford.EDU (Emma Pease)
Message-Id: <8903071857.AA11664@csli.Stanford.EDU>
To: friends@csli.Stanford.EDU
Subject: CSLI Calendar correction
The CSLI Seminar originally scheduled for Tuesday, 7 March, at 4 has
been rescheduled for Thursday, 9 March, at 2:15.
We apologize for the late notice.
CSLI SEMINAR
Indexicality and Quantified Modal Logic
Harry Deutsch
Illinois State University
Thursday, 9 March, 2:15
Cordura Conference Room
Relations between recent philosophy of language and the semantics of
modality (possible worlds semantics) have not been good. I attempt to
mediate the dispute by formulating quantified modal logic (QML) so as
to incorporate some insights of the "new theory of reference" (NTR).
This sheds some new light on both QML and the NTR.
∂07-Mar-89 1207 HEMENWAY@Score.Stanford.EDU Reports Ready
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Mar 89 12:07:52 PST
Date: Tue 7 Mar 89 12:05:14-PST
From: Sharon Hemenway <HEMENWAY@Score.Stanford.EDU>
Subject: Reports Ready
To: phd-adm@Score.Stanford.EDU
Message-ID: <12476176655.18.HEMENWAY@Score.Stanford.EDU>
We will have the reports for tomorrow's meeting ready by 2:00 this
afternoon, so please feel free to stop by if you would like a chance
to look them over before the meeting. They are in the same format as
the reports for the Round 1 meeting - a list by rank, an alpha list
and lists by rater.
Sharon
P.S. Just a reminder -- tomorrow's meeting is scheduled for 3:00 in
MJH 252.
-------
∂07-Mar-89 1334 X3J13-mailer hotel for march meeting
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Mar 89 13:34:03 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA03677g; Tue, 7 Mar 89 13:27:16 PST
Received: by challenger id AA28084g; Tue, 7 Mar 89 13:22:41 PST
Date: Tue, 7 Mar 89 13:22:41 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8903072122.AA28084@challenger>
To: x3j13@sail.stanford.edu
Subject: hotel for march meeting
I have reserved rooms for X3J13 but it is up to you to make your personal
reservations.
---jan---
∂07-Mar-89 1342 @Score.Stanford.EDU:nilsson@Tenaya Thinking Machines
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Mar 89 13:42:26 PST
Received: from Tenaya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 7 Mar 89 13:38:19-PST
Received: by Tenaya.Stanford.EDU (NeXT-0.8/NeXT-0.8)
id AA00976; Tue, 7 Mar 89 13:36:01 PST
Date: Tue, 7 Mar 89 13:36:01 PST
From: nilsson@tenaya.Stanford.EDU (Nils Nilsson)
Message-Id: <8903072136.AA00976@Tenaya.Stanford.EDU>
To: faculty@score.Stanford.EDU
Subject: Thinking Machines
Thinking Machines has come out with some smaller
machines---and less expensive. Some people from TM
are coming to Stanford on March 13 and would be
willing to meet with interested parties to talk about the
new machines. I told them I would sample whether or
not there is interest. All who would like to attend the
meeting proposed below pls respond to Joyce Chandler
(chandler@polya) so she can respond to TM.
Thanks, -Nils
----------
Begin forwarded message:
From: palmer@think.com
To: nilsson@score.Stanford.EDU
Cc: palmer@think.com, goldberg@think.com
Subject: Thinking Machines
Robert Goldberg and I are tentatively scheduled to be at
Stanford at 11 a.m. on March 13. Please confirm with a
list of likely attendees. Thank you in advance for the
opportunity to present the architecture of the Connection
Machine.
John Palmer
∂07-Mar-89 1403 X3J13-mailer Agenda DRAFT
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Mar 89 14:03:22 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA03717g; Tue, 7 Mar 89 13:56:36 PST
Received: by challenger id AA28137g; Tue, 7 Mar 89 13:52:01 PST
Date: Tue, 7 Mar 89 13:52:01 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8903072152.AA28137@challenger>
To: x3j13@sail.stanford.edu
Subject: Agenda DRAFT
X3J13 Committee Meeting Agenda DRAFT
March 28 - 30, 1989
Fairfax, VA
1 Call to Order, Tuesday, March 28, 9:00am
2 Opening Remarks and Introductions
- Opening Remarks, Bob Mathis (10 minutes)
- Introduction of attendees
- Future meetings, Jan Zubkoff (5 minutes)
3 Approval of Agenda
4 Approval of Minutes
5 Other Business
6 Cleanup Subcommittee Report, Larry Masinter
7 Coffee Break 10:30
8 Cleanup Subcommittee Report continuation
9 LUNCH 12:00
10 Cleanup Subcommittee Report continuation
11 Recess, 5:00pm
12 Call to Order, Wednesday, March 29, 9:00am
13 Character Subcommittee Report, Thom Linden (4 hours)
14 Coffee Break 10:30am
15 Character Subcommittee Report continuation
16 Lunch 12:00
17 Character Subcommittee Report continuation
18 Compiler Subcommittee Report, Sandra Loosemore (2 hours)
19 Break 3:00
20 Compiler Subcommittee Report continuation
21 Recess 5:00
22 Call to Order, Thursday, March 30, 9:00am
23 Editorial Subcommittee Report, Kathy Chapman (1.5 hours)
24 Coffee Break 10:30
25 Cleanup Subcommittee Report continuation
26 Lunch 12:00
27 Cleanup Subcommittee Report continuation
28 Break 3:00
29 Cleanup Subcommittee Report continuation
30 Adjournment 5:00pm
∂07-Mar-89 1427 @Score.Stanford.EDU:NA.PHL@Forsythe.Stanford.EDU Sunrise Club Breakfast
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Mar 89 14:26:53 PST
Received: from Forsythe.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 7 Mar 89 14:22:38-PST
Date: Tue, 7 Mar 89 12:34:10 PST
To: faculty@score
From: "Portia Leet" <NA.PHL@Forsythe.Stanford.EDU>
Subject: Sunrise Club Breakfast
NEXT SUNRISE CLUB:
Tuesday, March 28th
7:30 a.m.
Tresidder Union Oak Lounge West
SPEAKER:
Professor William Reynolds
The Donald W.Whittier Professor of Mechanical Engineering
TOPIC:
"Electronics and Optics in Thermoscientific Research"
If you plan to attend, please RSVP to Portia Leet 5-1585 or
na.phl@forsythe
To: SUNRISE
∂07-Mar-89 1429 X3J13-mailer registration list
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Mar 89 14:29:22 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA03769g; Tue, 7 Mar 89 14:22:28 PST
Received: by challenger id AA28211g; Tue, 7 Mar 89 14:17:54 PST
Date: Tue, 7 Mar 89 14:17:54 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8903072217.AA28211@challenger>
To: x3j13@sail.stanford.edu
Subject: registration list
X3J13 Attendee Information
03/07/89
Name Institute Paid L1 L2 L3
David Bartley TI -0- y y y
Paul Beiser HP -0- y y y
Mary Boelk Johnson Controls, Inc. -0- y y y
Kathy Chapman DEC -0- - - -
Jeff Dalton University of Ediburgh -0- y y y
Patrick Dussud Lucid, Inc. -0- y y y
Dick Gabriel Lucid, Inc. -0- y y y
David Gray TI 50.00 y y y
Masayuki Ida Aoyama Gakuin University -0- y y
Gregor Kiczales Xerox Corp. -0- y y y
Dieter Kolb Siemans -0- y y y
Tim Koschmann Xerox -0- y y y
Aaron Larson Honeywell S&RC -0- y y y
Kevin Layer Franz, Inc. 50.00 y y y
Thom Linden IBM 50.00 y y y
David Loeffler MCC 50.00 y y y
Sandra Loosemore University of Utah -0- y y y
Barry Margolin Thinking Machines 50.00 y y y
Larry Masinter Xerox Corp. -0- y y y
Robert Mathis CONTEL -0- y y y
David Moon Symbolics -0- y y y
Cris Perdue Sun Microsystems -0- y y y
Dan Pierson Encore Computer -0- y y y
Kent Pitman Symbolics -0- y y y
Guy Steele Thinking Machines -0- y y y
Paul Tucker IBM -0- y y y
Walter van Roggen DEC -0- y y y
JonL White Lucid, Inc. -0- y y y
Jan Zubkoff Lucid, Inc. -0- y y y
∂07-Mar-89 1448 @Score.Stanford.EDU:wheaton@Athena.Stanford.EDU IBM RT
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Mar 89 14:47:31 PST
Received: from Athena.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 7 Mar 89 14:44:51-PST
Received: by Athena.Stanford.EDU (5.61/25-eef) id AA04765; Tue, 7 Mar 89 14:44:20 -0800
Date: Tue, 7 Mar 89 14:44:20 -0800
From: George S Wheaton <wheaton@Athena.Stanford.EDU>
Message-Id: <8903072244.AA04765@Athena.Stanford.EDU>
To: ac@score
Subject: IBM RT
Some time ago the department got some RT's that had been housed and used at
TAC. James Wilson brought them down here, used some in administrative
computing and gave some to faculty for research projects. We may now have
one extra machine. Does anyone out there need an RT? I'm not sure how to
decide who should get it if there are multiple requests - if anyone asked
and didn't receive one when they first arrived from TAC, please let me
know.
Be forewarned - this comes with no support, warranties, or gurantees, but
individuals have been installing upgrades and new releases on other
machines throughout the dept.
gw
∂08-Mar-89 0520 X3J13-mailer Issue: PLUS-ABNORMAL
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 8 Mar 89 05:20:36 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA27193; Wed, 8 Mar 89 05:18:36 PST
Message-Id: <8903081318.AA27193@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA27193; Wed, 8 Mar 89 05:18:36 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 8 Mar 89 08:18
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: PLUS-ABNORMAL
Issue: PLUS-ABNORMAL
References: +, ++, +++ (p. 325)
Category: CLARIFICATION
Edit history: 1-MAR-89, Version 1 by Chapman
Problem Description:
The description of +, ++, and +++
does not mention the possibility of abnornal termination of
the evaluation of the variable {\tt +}.
Are the values associated with {\tt ++},
and {\tt +++} are updated?
Proposal (PLUS-ABNORMAL:UPDATE)
If the evaluation of the variable {\tt +} is aborted for some reason,
then the values associated with {\tt ++},
and {\tt +++} are updated.
Rationale:
This clarification is primarily to establish the contents of these
variables in all cases.
Current Practice:
VAX Lisp updates the values.
Adoption Cost:
?
Benefits:
Disambiguity.
Conversion Cost:
?
Aesthetics:
None.
Discussion:
∂08-Mar-89 0523 X3J13-mailer Issue: PLUS-ABNORMAL
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 8 Mar 89 05:22:59 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA27292; Wed, 8 Mar 89 05:21:03 PST
Message-Id: <8903081321.AA27292@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA27292; Wed, 8 Mar 89 05:21:03 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 8 Mar 89 08:20
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: PLUS-ABNORMAL
Sorry about that. Disregard that last issue. It should have been sent
to cl-cleanup.
∂08-Mar-89 1023 STAGER@Score.Stanford.EDU Final Exams
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Mar 89 10:23:51 PST
Date: Wed 8 Mar 89 10:17:15-PST
From: Claire Stager <STAGER@Score.Stanford.EDU>
Subject: Final Exams
To: instructors@Score.Stanford.EDU, bil@SUN.COM
cc: tas@Score.Stanford.EDU, stager@Score.Stanford.EDU
Office: CS-TAC 29, 723-6094
Message-ID: <12476419139.20.STAGER@Score.Stanford.EDU>
It's time again to start planning for final exams. (Refer to page 6
of the Winter Quarter Time Schedule if you have questions about Dead Week
policy, or what the examination schedule is.)
Please respond to the following by FRIDAY, MARCH 10:
1. Have you moved to a new room/time (and not let me know)? If so, where
and when are you meeting now?
2. Are you giving a take-home exam instead of an in-class exam?
Do you plan on giving a final exam this quarter?
3. Will you need additional space in order to provide alternate seating?
If so, how many TOTAL seats will you be requiring?
4. Are you giving an alternate exam in addition to your regularly scheduled
exam? If so what day/time, and what size of a room will you be needing?
Please Note:
"Classes starting at unusual times (e.g. 2:30pm or 2:45pm)hold exams in the
same time slots as classes starting at the regular time with the same hour
designation. So, the final examination in the examples above would be given
under the 2:15 time slot."
Contact me at Stager@Score, or 3-6094, if you have any questions.
Thanks.
Claire
-------
!
-------
∂08-Mar-89 1134 @Score.Stanford.EDU:nilsson@Tenaya faculty meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Mar 89 11:34:19 PST
Received: from Tenaya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 8 Mar 89 11:31:15-PST
Received: by Tenaya.Stanford.EDU (NeXT-0.8/NeXT-0.8)
id AA02145; Wed, 8 Mar 89 11:28:59 PST
Date: Wed, 8 Mar 89 11:28:59 PST
From: nilsson@tenaya.Stanford.EDU (Nils Nilsson)
Message-Id: <8903081928.AA02145@Tenaya.Stanford.EDU>
To: ac@score.Stanford.EDU
Subject: faculty meeting
Cc: nilsson, wheaton@athena.Stanford.EDU, bscott@score.Stanford.EDU,
bureaucrat@polya.Stanford.EDU
The theory committee has requested a faculty meeting
of all faculty to hear their recommendations about new
appointments. In order to maximize Stanford's chances
of getting our preferred candidates and to meet the
University's schedule for making appointments, we need
to have this meeting next week. Again, I'm very sorry
for the short notice. I agree with those who said that
if we are to have meetings, let's at least have them on
the regularly scheduled day and time, which is
Tuesday at 2:30. So, we will have a faculty meeting
on Tuesday, March 14 at 2:30 in MJH 146, and letters on the preferred candidates
will be available from Betty Scott for reading ahead
of time.
We will finish the meeting in time for us to hear Michael
Dertouzos, Director of MIT's LCS, who will be the
colloquium speaker at 4:15 on Tuesday.
News items: Operations Research did approve offering
an appointment to Eva Tardos, but they approved only
1/4 billet----instead of 1/2. That means we will have
to ask the Provost for 3/4 of a billet (citing affirmative
action considerations)----which we are doing. Bernd
Sturmfels has informed Don Knuth that he probably will
accept an offer from Cornell instead of Stanford.
-Nils
∂08-Mar-89 1306 @Score.Stanford.EDU:golub@na-net.stanford.edu NSF visitor
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Mar 89 13:06:09 PST
Received: from bravery.stanford.edu by SCORE.STANFORD.EDU with TCP; Wed 8 Mar 89 13:01:49-PST
Received: by bravery.stanford.edu (4.0/inc-1.5)
id AA10281; Wed, 8 Mar 89 13:14:42 PST
Date: Wed, 8 Mar 1989 13:14:36 PST
From: Gene H. Golub 415/723-3124 <golub@na-net.stanford.edu>
To: faculty@score.stanford.edu
Subject: NSF visitor
Message-Id: <CMM.0.88.605394876.golub@>
Kamal Abdali of NSF's Numeric and Symbolic Computing will be here on
March 28. Please let him know if you wish to see him.
Gene
---------------
Return-Path: <kabdali@note.nsf.gov>
Received: from argus.Stanford.EDU by patience.stanford.edu (4.0/inc-1.5)
id AA23145; Wed, 8 Mar 89 10:28:32 PST
Received: from note.NSF.GOV by argus.Stanford.EDU with TCP; Wed, 8 Mar 89 10:19:12 PST
To: golub@patience.Stanford.EDU
Subject: Visiting PIs
From: "S. Kamal Abdali" <kabdali@note.nsf.gov>
Date: Wed, 08 Mar 89 10:37:21 -0500
Sender: kabdali@note.nsf.gov
Message-Id: <8903081037.aa28449@note.nsf.gov>
(On the instructions of my government) I'm using the opportunity of a
conference attendence to make some site visits. I would like to visit
you sometime during the morning of 3/28. Could you please let me
know if this is convenient for you.
The main purpose is to visit PIs and prospective PIs. Of course, I'll
also be glad to meet anyone who is interested in the Numeric and Symbolic
Computation. If you have any colleagues who would like to see me during
this visit, please ask them to contact me.
∂08-Mar-89 1509 @Score.Stanford.EDU:berglund@polya.Stanford.EDU Ph.D. Student Meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Mar 89 15:09:39 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 8 Mar 89 15:04:32-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA21457; Wed, 8 Mar 89 15:04:41 -0800
Date: Wed, 8 Mar 89 15:04:41 -0800
From: Eric J. Berglund <berglund@polya.Stanford.EDU>
Message-Id: <8903082304.AA21457@polya.Stanford.EDU>
To: faculty@score, phd@score
Subject: Ph.D. Student Meeting
On Monday, March 6, a meeting was held of the Ph.D. students in our department.
It was advertised with the title "Extraordinary Ph.D. Student Meeting:
Problems in the Ph.D. Program--Real and Imagined", and was called by yours
truly, with the help of the CS student bureaucrats. I called it
"Extraordinary" because 1) we usually have only one meeting a quarter, and
2) I thought more people would show up. I was pleased with the turnout; I
think we had about 40 or 45 students there, enough to fill all the chairs
in 146 Jacks.
I had two main purposes for calling the meeting:
1. To demonstrate to myself and my fellow students that there are many
more students basically satisfied with the program than the last year's
worth of discussion would indicate.
2. To improve our recruiting efforts.
It isn't clear to me that I accomplished either one, though subsequent
unscientific sampling indicates that I didn't hurt my causes either.
I mention my motives now to indicate that I was not an unbiased, neutral
observer either during the meeting or since. If you've read my agenda
for the meeting (there's a copy at the end of this note), you'll note
that there were clues to my biases, but they were not obvious. Most students
attended the meeting, I believe, to be allowed to express their opinions
about improving the program, not to further my unannounced purposes.
In any case, I was hoping to find a student consensus about the program.
Obviously, there was more consensus on some issues than on others. One
of the least debated opinions was that I should be forced to write a
summary of the meeting for presentation to the faculty. Hence, this note.
(I am sending this note only to the phd@score and faculty@score mailing
lists, not to the phd-program bboard, which I understand is still accessible
to any USENET reader. I retain all copyright privileges I've got: please
ask my permission before distributing this further. I'm not interested
in publicizing my comments around the country.
(I don't know what to suggest for responses. People should use their
own judgment and conscience to decide what they want to post to bboard,
and what they want to clutter everyone's mailbox with, and what they
should keep to themselves. The bureaucrats talked about having another
student meeting to continue the discussion about two weeks from now.)
At the beginning of the meeting, I asked two questions. Their flaws are
obvious and were pointed out, but the results might still mean something.
Question 1 is whether our department overall is better than, worse than,
or approximately equal to those at CMU and MIT. The vote was about 5
betters, 5 worses, 10 sames, and 20 or more I-don't-know-or-I-think-the-
question-is-flaweds.
Question 2 is whether our department is improving, declining, or staying
about the same. We got about 6 improvings, 8 declinings, 10 staying sames,
and the rest not voting.
From there I wanted to first collect a list of consensus good things
about the department, and then consensus bad things. I don't think this
is the agenda most people had in mind, however, so it wasn't too far
into the list of good things that people went more into free-for-all
commenting. Since the discussion was disorganized, I'm going to present
a bunch of things said and my impression of the consensus or lack of
same on each. Consider this first list a warmup for the larger issues
to be discussed later.
1. One of our strongest points of agreement was that the raw talent
in the department, both faculty and students, is a very strong
positive for us. The University as a whole and the surrounding
area were also recognized as good things.
2. Systems seems to have gone from one of our weakest areas to our
strongest. In particular, students who work over in CIS seem
more pleased than most about their educational experience.
3. Though we appreciate the effort that the department is making to
rebuild the theory side of the department, and Jack Snoeyink's
updates on the state of that effort, a lot of us still have trouble
with the idea of telling theory students that Stanford is the
place to be. It seemed to theory people that there are 5 or 6
places to go before Stanford as we exist today. It was noted
and appreciated that Andrew Goldberg, John Mitchell, and the visiting
people this year had done a lot for some of the problems, but a more
permanent solution is needed.
4. There was one complaint about the state of our experimental AI
program, but it didn't lead to much of a discussion. Stanford
would seem, by consensus again, to be a fine place to do theoretical
AI work, if certain issues (to be discussed later in this note)
were fully addressed.
5. Everyone who knows seems to think Robotics is doing really well.
6. There were some comments about the frustration of knowing what
area one wanted to work in and being unable to find a faculty
member with the interest and/or expertise in that area. (Experimental
AI seems to fit here.) It's not clear to me how widespread this
feeling is. One person mentioned afterward that there may be some
value in having a faculty member or two with extremely eclectic
tastes to pick up people who don't fit elsewhere.
The vast majority of our discussion, however, concentrated on the
following three issues:
1. Department Fragmentation.
A large majority seemed to think that we have a significant
problem with communication across research areas and groups.
Students feel frustrated that they do not know what other
groups are doing, and especially frustrated that the faculty
don't seem to communicate well among themselves. One student
wondered afterward how our department compares to others in
the number of research contracts with multiple PIs from the
department. (A couple personal side comments: a) It may be
that this fragmentation is an inevitable consequence of growth.
b) Multiple PI contracts could do a lot for helping to solve
all 3 of our perceived main problems.)
2. Funding.
Several (1st and 2nd year?) students expressed frustration with
funding limitations on their research directions. At least
one mentioned having an experience in which he approached a
faculty member who would have been happy to advise him in his
preferred area, but who was unable to provide support. Once
again, the alleged CMU model was examined. Is it true that
all research funds are pooled by their faculty? How can that
be legal? This has always been a negative in our recruiting:
the feeling among our students that funding might limit our
options, and the rumor that it doesn't limit the options of
students at other schools. (We seem to need more facts here:
it may be that students at other schools are in exactly the
same situation. If so, this observer thinks this concern might
go away.)
There was some speculation that the senior faculty might not
be holding up their end in obtaining support both for students
AND for junior faculty who might have more difficulty attracting
research grants. Some of us think that junior faculty are
more accessible, more enthusiastic, and have more opportunity
to provide the kind of close contact we need, but that they
are limited by the lack of support, financial and otherwise,
that they receive from the senior faculty.
3. Faculty Supervision and Access.
This was by far the most important issue to virtually every
single one of us. With rare exceptions (some students of
Jean-Claude Latombe, Vaughan Pratt, and Jeff Ullman
seemed to be among the exceptions) students feel
that they are not getting the quantity and quality of faculty
direction that they expected when they decided to come to
Stanford. I cannot overstate how important this theme was
to the discussion. To give you some idea of its magnitude,
let me point out that there was only one, maybe two, comments
about the comp, and none about the qual. Students seem to
care about improving the comp but, right now at least, we
are much more concerned about a lack of exposure to and
guidance from the faculty.
Younger students feel they are not being told and shown how
to begin research. Even if a faculty member suggests a starting
project, rather than just saying "Get the comp out of the way
first", the connection between that project and doing research
is not articulated.
Senior students feel that having spent 2 or 3 years passing
comps and quals, they are hardly more qualified to do research
than when they began. In particular, they feel that they have
not had the chance to really watch the faculty DOING research.
(Another personal note: I think part of the problem is the
physical separation in Jacks of faculty from students. I hope
the architecture of the new building gathers research groups
together rather than stashing the students in jungles far
removed from the faculty.)
Someone suggested that students everywhere will always complain
and that our problems are the same as those in similar places.
The student consensus was that though they may complain in other
departments, we feel that one measure of our interaction with
faculty was the number of papers we write jointly with faculty
members, and that by that measure we're doing significantly
worse than students at comparable schools.
We spent quite a bit of time (relatively--the meeting was
only scheduled to be 45 minutes and went for an hour) talking
about the value of our fellow students as advisors and guides.
Several students (especially theory students?) felt that their
research branched significantly far from what others were doing
that fellow students could not really contribute. There were
others who felt quite strongly that concentrating on the
negative of faculty remoteness was not helpful: that we could
successfully use each other more as a replacement. No one
seemed overly thrilled that we might have to be looking for
a replacement.
Related to all of this is some resentment over faculty
complaints about the time it takes us to graduate. We note
that CMU and MIT take just as long to graduate their students,
which implies that the field might just require this much time.
In any case, I think the consensus was that time to graduation
is primarily a problem with faculty direction, not student
capability or work ethic.
As the meeting was winding down, I asked whether we as a group
would be willing to spend ten more hours per week in our offices
if the faculty did the same. The vocalized reaction, I'm afraid,
was that it was easy for us to promise our ten hours because the
faculty would never give theirs.
Near the end of our meeting, I revealed that my primary purpose for
calling the meeting was to show my fellow students that most of them
felt things were pretty good, and that therefore we should be happy
to help the recruitment effort for next year's students. It seemed
(seems) clear that I did not achieve the first part of that objective,
though a number of students have told me since that they were pleased
to find out that not everyone thinks we're going to hell in a handbasket.
We talked about our willingness to help with recruiting. Several people
stressed the importance of honesty in our presentation (especially with
respect to the state of the theory area) but for the most part I think
we recognize the importance of the recruiting effort, especially since
we have to depend on incoming students as our colleagues.
So here are my current conclusions about the meeting.
There remains a fundamental optimism among students, at least among
those who attended the meeting. We feel that the talent and
the desire is here to make our department the best. It could just be
our arrogance, but we came to the meeting believing that our ideas would
make the department better: the implication is that we think there's
something worth working on. Most of us can, in good conscience,
recommend this as a good place to learn.
The down side is, that even with a biased moderator (yours truly)
whose agenda was to show my fellow students that those with complaints
were in the minority, the consensus insisted that improvements have
to be made. (Evidence of my bias: one student began the list
of bad things about the department by saying, "First year students
are second class citizens." I refused to accept the comment, insisting
that I would not enter an item on our list which I claimed was the
equivalent of "Things suck." One student afterward accused me of
calling the meeting under the urging of Mike Genesereth--my advisor
and the chair of the Ph.D. committee.) Despite this bias, the main student
message comes through loud and clear: We don't feel that we are
being effectively and efficiently taught how to do research.
Your reporter and instigator,
--Eric J. Berglund
P.S. This Appendix is the note I sent to Ph.D. students telling them
about the meeting:
I asked Andrew to call the meeting on Monday so that we could
get together and see if there's a consensus among the PhD students
about the current state and direction of the PhD program. Among
the more provocative opinions I've heard recently while talking
to people about this:
--Why are the faculty nagging us about time to graduation? It's
their fault, not ours.
--Students today are lazier than they were ten years ago.
--We really don't have much of a problem at all: just a few people
who whine and complain a lot.
What I propose to do, unless given a better suggestion is to see
if we can't reach a relatively quick consensus on short answers to
the following questions:
1. How good or bad is our program?
2. Is it improving or declining?
3. What's good about it?
4. What's bad about it?
5. What problems are over- and underrated?
We'll take a little longer to see if there's any hope for a consensus
on these two:
6. What causes the existing problems, if any?
7. What can realistically be done to fix the problems?
Finally, I'd like to take 5 or 10 minutes at the end to talk about
how recruiting should be handled when the program may not be perfect.
Please send me suggestions for any changes to this plan of attack,
and then bring yourself and all your PhD buddies to 146 Jacks at
12:15 ('til 1:00) on Monday. This coming Monday.
--Eric
∂08-Mar-89 1610 misha@polya.Stanford.EDU AFLB tomorrow!
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Mar 89 16:10:26 PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA26346; Wed, 8 Mar 89 16:05:36 -0800
Date: Wed, 8 Mar 89 16:05:36 -0800
From: Michael Kharitonov <misha@polya.Stanford.EDU>
Message-Id: <8903090005.AA26346@polya.Stanford.EDU>
To: aflb-all@polya.Stanford.EDU
Subject: AFLB tomorrow!
The second meeting of AFLB this week will be at its regular
time and place, at 12:30 on Thursday (tomorrow) in room 352.
Title: LOWER BOUNDS FOR COMPUTATIONS WITH THE FLOOR OPERATION
Speaker: Baruch Schieber, IBM - Research Division,
T.J. Watson Research Center, Yorktown Heights, NY 10598
ABSTRACT
We prove an Omega ((log n)**0.5) lower bound on the depth
of any decision tree with operations {+,-,*,/,floor,<}, that
decides whether an integer is a perfect square, for any n-bit
integer. We then extend the arguments to obtain an Omega(loglog n)
lower bound on the depth of any decision tree with operations
{+,-,*,/,floor,<}, that decides whether two integers are
relatively prime, for any two n-bit integers. Although our lower
bounds are not tight, they are the first non-trivial bounds
for natural problems in the presence of the floor operation.
A novel technique for handling the floor operation is presented.
The same technique can be used to derive lower bounds for many
other problems.
Finally, we show that the same lower bounds hold for the time
complexity of RAMs with the same set of arithmetic operations.
This is a joint work with Yishay Mansour and Prasoon Tiwari.
∂08-Mar-89 1649 X3J13-mailer February 21 Ballot
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 8 Mar 89 16:49:01 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA05400g; Wed, 8 Mar 89 16:42:11 PST
Received: by challenger id AA00614g; Wed, 8 Mar 89 16:37:36 PST
Date: Wed, 8 Mar 89 16:37:36 PST
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8903090037.AA00614@challenger>
To: x3j13@sail.stanford.edu
Subject: February 21 Ballot
Here is Lucid's vote. There are two conditional acceptances. One is
because several of us are rewriting the error terminology yet again.
The other is section 6.1 where I want to look at the notation
introduced there once more. Also, there are some minor problems with
the rest of the section, (for example, fill pointers and pathnames
should be described somewhere else.) The sections on CLOS (1.8, 2.3,
2.4, 2.5) were put together by Kathy, Linda DeMichiel, and me, so I
think they're ok from the CLOS committee's point of view.
________________________________________________________________________
Issue or section name | Version | Y | I | A |
------------------------------------------------------------------------
CUT-OFF-DATES | 4 | Y | | |
------------------------------------------------------------------------
ERROR-TERMINOLOGY | 5 | | I | |
------------------------------------------------------------------------
FONTS | 2 | Y | | |
------------------------------------------------------------------------
TOC | 1 | Y | | |
------------------------------------------------------------------------
Section 1.8 | 5.8 | Y | | |
------------------------------------------------------------------------
Section 2.3 | 5.8 | Y | | |
------------------------------------------------------------------------
Section 2.4 | 5.8 | Y | | |
------------------------------------------------------------------------
Section 2.5 | 5.8 | Y | | |
------------------------------------------------------------------------
Section 6.1 | 5.8 | | I | |
------------------------------------------------------------------------
-rpg-
∂08-Mar-89 1719 emma@csli.Stanford.EDU CSLI Calendar, 9 March, $:19
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Mar 89 17:19:36 PST
Received: by csli.Stanford.EDU (4.0/inc-1.0)
id AA07817; Wed, 8 Mar 89 16:33:16 PST
Date: Wed, 8 Mar 89 16:33:16 PST
From: emma@csli.Stanford.EDU (Emma Pease)
Message-Id: <8903090033.AA07817@csli.Stanford.EDU>
To: friends@csli.Stanford.EDU
Subject: CSLI Calendar, 9 March, $:19
C S L I C A L E N D A R O F P U B L I C E V E N T S
_____________________________________________________________________________
9 March 1989 Stanford Vol. 4, No. 19
_____________________________________________________________________________
A weekly publication of The Center for the Study of Language and
Information, Ventura Hall, Stanford University, Stanford, CA 94305
____________
CSLI ACTIVITIES FOR THIS THURSDAY, 9 March 1989
2:15 p.m. CSLI Seminar
Cordura Hall Indexicality and Quantified Modal Logic
Conference Room Harry Deutsch
Illinois State University
Abstract below
3:30 p.m. Tea
Ventura Hall
____________
ANNOUNCEMENT
Please note that the CSLI Seminar originally scheduled for 7 March is
now on 9 March at 2:15.
The CSLI Calendar will not be published on 16 and 23 March.
____________
THIS WEEK'S CSLI SEMINAR
Indexicality and Quantified Modal Logic
Harry Deutsch
Illinois State University
Thursday, 9 March, 2:15
Cordura Conference Room
Relations between recent philosophy of language and the semantics of
modality (possible-worlds semantics) have not been good. I attempt to
mediate the dispute by formulating quantified modal logic (QML) so as
to incorporate some insights of the "new theory of reference" (NTR).
This sheds some new light on both QML and the NTR.
____________
SYMBOLIC SYSTEMS FORUM
Ontology and Computers
Ruben Kleiman
Apple Intelligent Agents Group
Friday, 10 March, 3:15
Room 60:61N
This talk will be about artificial intelligence and knowledge
representation, focusing on how to encode knowledge into a computer.
On one hand, Winograd, Flores, and Putnam have advocated a
phenomenological view that abandons the standard mentalist position.
On the other hand, there are also many people (Hayes, McCarthy,
Dennett, and most AI workers) who keep the mentalist position. Dr.
Kleiman will attempt to reconcile these two philosophical positions.
____________
LINGUISTICS DEPARTMENT COLLOQUIUM
A Union Analysis of Noun Incorporation
Donna Gerdts, SUNY at Buffalo
Friday, 10 March, 3:15
Cordura Conference Room
Noun incorporation (NI) has been widely discussed from many
viewpoints; this paper presents yet another analysis of this
phenomonon, one based on three previously proposed and independently
instantiated relational constructs: union, multiattachment, and
cancellation. Not only does this treatment provide an analysis at no
cost to the grammar, but it allows for a typology of NI constructions
appropriate for the array of data currently attested in natural
languages. First, we take a quick look at five other analyses pointing
out their empirical inadequacies. The strength of the union analysis
is that it avoids the limitations of other treatments while
nevertheless presenting a constrained view of NI constructions.
____________
COMMONSENSE AND NONMONOTONIC REASONING SEMINAR
Relating Default and Autoepistemic Logics
Wiktor Marek and Miroslaw Truszczynski
University of Kentucky
Monday, March 13, 3:15pm
MJH 301
We introduce a classification of nonmonotonic context-dependent
reasonings according to the way context is used in derivations. A
reasoning is symmetric if context is used to derive both positive and
negative information. A reasoning is asymmetric if context is applied
to derive negative information only. In the talk we concentrate on
symmetric and asymmetric reasonings in default and autoepistemic
logics. They give rise to several classes of objects: weak extensions
and extensions in default logic, and expansions and robust expansions
in autoepistemic logic. Our results establish correspondence between
weak extensions and expansions (both notions are related to symmetric
reasonings) and extensions and robust expansions (these notions are
related to asymmetric reasonings). We also find an exact character of
the correspondence between notions based on the parsimony principle:
minimal sets closed under defaults and stable sets with minimal
objective parts. This multilevel correspondence between default and
autoepistemic logics pinpoints the exact character of the equivalence
of their expressive powers.
∂08-Mar-89 1741 X3J13-mailer Feb. 21 Letter Ballot: editorial issues
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Mar 89 17:41:03 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 553455; Wed 8-Mar-89 20:38:11 EST
Date: Wed, 8 Mar 89 20:37 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Feb. 21 Letter Ballot: editorial issues
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: <19890306214441.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890309013751.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
I'd like to change the Symbolics vote, since you told me two things
that none of us here knew before: that there will be an opportunity
for cleaning up these sections even after they are voted in now, and
that the CLOS sections had already been carefully reviewed by Gabriel
and that Gregor had said he was satisfied with them. As a result,
we're changing our vote on sections 2.3, 2.4, and 2.5 from I to Y.
The other three I votes should remain. For ERROR-TERMINOLOGY because
it seems to be actively changing, for section 1.8 because the section
is sketchy, and for section 6.1 because we haven't really understood
it yet. Section 6.1 looks fundamental, do you think it's important
to get a vote on it as soon as possible? If so, we at Symbolics could
try to concentrate our efforts there.
I'd also like to clarify the meaning of this paragraph of our reply:
The five numbered sections: We approve these in principle, but aren't
ready to cast them in concrete. We haven't had time to review them with
the extreme care warranted for a language standard, and don't know who
else, if anyone, has reviewed them that thoroughly.
This was certainly not meant to give the impression that we were
refusing to review this stuff! The problem is simply that except for
Pitman, who is on the editorial committee, no one here had seen any of
this before two weeks ago. Also as it happens it is an extremely busy
time for us right now. Two weeks would not enough time for a really
careful review even in slack times, but at the time it was impossible.
I personally plan to try to review the entire standard carefully, as
well as to browbeat several other people at Symbolics into doing careful
review of either the entire standard or selected sections for their
areas of expertise. That will take a significant amount of time, of
course, probably several months.
∂09-Mar-89 1122 kuder@russell.Stanford.EDU SSP Internship lunch
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Mar 89 11:22:16 PST
Received: by russell.Stanford.EDU (4.0/inc-1.0)
id AA24457; Thu, 9 Mar 89 11:23:22 PST
Date: Thu 9 Mar 89 11:23:21-PST
From: Margie Kuder <KUDER@CSLI.Stanford.EDU>
Subject: SSP Internship lunch
To: ssp-faculty@russell.Stanford.EDU, ssp-students@russell.Stanford.EDU
Message-Id: <605474601.0.KUDER@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
The following are on our list for the Internship Lunch on March 16 at noon
at Cordura Hall. If you are not on the list and want to attend, please
let me know by Monday, March 13 and we will add you to the list and order
lunch for you also.
Faculty:
Peter Sells
Stan Rosenschein
John Etchemendy
Jon Barwise
Helen Nissenbaum
Barbara Tversky
Stanley Peters
Students:
Mark Burns Mike Lenz Ann Podiozny
Michael Frank Chris Weyand John Lynch
Al Sargent Kimberly Claffy Paul Glauthier
Stefan Heck Mark Torrance Rafie Furst
Laura Wasylenski Soeun Park John Wesseling
Reid Hoffman Michael Korcuska
-------
∂09-Mar-89 1340 X3J13-mailer Issue: SUBSETTING-POSITION
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89 13:40:03 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554074; Thu 9-Mar-89 16:37:07 EST
Date: Thu, 9 Mar 89 16:36 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SUBSETTING-POSITION
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: <8902200927.AA06837@decwrl.dec.com>
Message-ID: <19890309213655.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
I support SUBSETTING-POSITION:NONE. I think that subsets are
a good idea, but I also think that the X3J13 process has no
chance at all of coming up with a subset that is useful to
anyone in the time available. Therefore I think the standard
should propose no subsets, but should not contain any statement
(unlike, I think, Ada) to the effect that subsets are forbidden
or a bad idea.
∂09-Mar-89 1345 X3J13-mailer Issue: EXTENTIONS-POSITION
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89 13:45:26 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554086; Thu 9-Mar-89 16:42:43 EST
Date: Thu, 9 Mar 89 16:42 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXTENTIONS-POSITION
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: <8902242224.AA13754@decwrl.dec.com>
Message-ID: <19890309214233.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor EXTENSIONS-POSITION:DOCUMENTATION.
I oppose EXTENSIONS-POSITION:DISABLE because it mandates a
particular development environment feature, but Common Lisp
has avoided saying anything about development environments
since that is an area of extreme controversy.
Gabriel's position of standing mute would be okay with me.
∂09-Mar-89 1349 X3J13-mailer Issue: MACRO-AS-FUNCTION
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89 13:49:18 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554092; Thu 9-Mar-89 16:46:30 EST
Date: Thu, 9 Mar 89 16:46 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: MACRO-AS-FUNCTION
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu
In-Reply-To: <8902242236.AA14651@decwrl.dec.com>
Message-ID: <19890309214619.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Why don't we just change PROG1 and PROG2 to functions, now that
we have clarified that functions evaluate their arguments in
left-to-right order?
∂09-Mar-89 1350 X3J13-mailer Issue: UNSOLICITED-MESSAGES (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89 13:50:21 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554094; Thu 9-Mar-89 16:47:35 EST
Date: Thu, 9 Mar 89 16:47 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: UNSOLICITED-MESSAGES (Version 2)
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu
In-Reply-To: <8902242237.AA14750@decwrl.dec.com>
Message-ID: <19890309214725.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
UNSOLICITED-MESSAGES:NOT-TO-SYSTEM-USER-STREAMS is okay.
∂09-Mar-89 1352 X3J13-mailer Issue: UNSPECIFIED-DATATYPES (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89 13:52:35 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554096; Thu 9-Mar-89 16:49:52 EST
Date: Thu, 9 Mar 89 16:49 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: UNSPECIFIED-DATATYPES (Version 2)
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu
In-Reply-To: <8902242237.AA14708@decwrl.dec.com>
Message-ID: <19890309214942.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
I oppose UNSPECIFIED-DATATYPES:NO-EXCEPT-AS-EXPLICITLY-ALLOWED
on the grounds that it is unnecessary and that the problem it's
attempting to address (making it possible to check conformance
by machine) is impossible to solve.
∂09-Mar-89 1357 X3J13-mailer Issue: EXTRA-SYNTAX (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89 13:57:48 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554101; Thu 9-Mar-89 16:55:10 EST
Date: Thu, 9 Mar 89 16:54 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXTRA-SYNTAX (Version 4)
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: <8902271015.AA14142@decwrl.dec.com>
Message-ID: <19890309215459.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
I oppose EXTRA-SYNTAX:NO. The rationale says
It would be very difficult for a program-analyzing-program to detect
such an extension. Non-portable programs could easily result.
I can't see what's hard about detecting use of additional syntax not
specified -- that seems to be the easiest to detect of any
nonconformance. To take the canonical example of extending IF to allow
more than three subforms, surely it is very easy for a
program-analyzing-program to detect an invocation of IF with more than
three subforms and complain that the program is non-conforming.
∂09-Mar-89 1406 X3J13-mailer Issue: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 9 Mar 89 14:06:06 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 554109; Thu 9-Mar-89 17:03:09 EST
Date: Thu, 9 Mar 89 17:02 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS (Version 3)
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: <8902271016.AA14193@decwrl.dec.com>
Message-ID: <19890309220257.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
I oppose both proposals. The adoption cost is:
Implementors will be required to determine which parts of their
implementations are conforming and which parts aren't. Implementors
will have to provide a candidate list of exceptions to the editorial
committee.
The second sentence strikes me as a lot of extra work that will just
delay closure on the standard.
The stated benefits are:
It will be more possible to write portable programs. Also, future
standards will be less likely to make changes that are incompatible
with current implementations.
I don't believe in the first benefit. This issue does not affect the
ability to write portable programs in any significant way. It only
affects whether particular implementations are more or less useful as
development tools for checking conformance. I believe that development
tools for checking conformance are a valuable item for which market
demand exists, but are not within the purview of X3J13.
The second benefit is true. However there are a large number of other
ways that future standards could be incompatible with current
implementations, none of which have been ruled out. For example, any
implementation that makes symbols accessible to the USER package other
than symbols in the LISP package risks name conflicts with future
additions to the LISP package. It's simply a fact of life that any
extension might be incompatible with an eventual standard; pioneers can
never be sure that everyone will follow in their exact footsteps.
∂09-Mar-89 1433 X3J13-mailer Issue: EXTRA-SYNTAX (Version 4)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 9 Mar 89 14:33:19 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA06700g; Thu, 9 Mar 89 14:26:23 PST
Received: by challenger id AA02174g; Thu, 9 Mar 89 14:21:48 PST
Date: Thu, 9 Mar 89 14:21:48 PST
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8903092221.AA02174@challenger>
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: EXTRA-SYNTAX (Version 4)
The rationale says:
``It would be very difficult for a program-analyzing-program to detect
such an extension. Non-portable programs could easily result.''
In fact the error terminology says this about extending the syntax
when it's allowed:
``Implementations are permitted to define unambiguous extensions to
the syntax of the construct being described. No conforming code can
depend on this extension. Implementations are required to document
each such extension. All conforming code is required to treat the
syntax as meaningless.''
Thus, the only syntactic extensions allowed would be those that
program analysis programs could detect.
There are some cases where we wish to disallow extensions and some
cases where we don't care. DEFCLASS is an example of one place we wish
to keep people away from. If there are vastly more places where we
don't care, that should be the default. I think it would take a
careful editorial process to decide whether it's easier to defaultly
allow or defaultly disallow. I think this issue is quite different
from that of extensions in general.
-rpg-
∂09-Mar-89 1539 X3J13-mailer Re: Issue: UNSPECIFIED-DATATYPES (Version 2)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 9 Mar 89 15:39:49 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA04997; Thu, 9 Mar 89 16:37:40 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA10028; Thu, 9 Mar 89 16:37:35 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903092337.AA10028@defun.utah.edu>
Date: Thu, 9 Mar 89 16:37:28 MST
Subject: Re: Issue: UNSPECIFIED-DATATYPES (Version 2)
To: chapman%aitg.dec@decwrl.dec.com
Cc: x3j13@sail.stanford.edu,
David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Thu, 9 Mar 89 16:49 EST
I agree with Moon. Leaving the behavior undefined gives an
implementation permission to do anything it wants, including starting
WWIII. "Anything" ought to include defining some useful behavior for
the situation, such as asking me if I really want to launch the
missiles.
-Sandra
-------
∂09-Mar-89 1613 TAJNAI@Score.Stanford.EDU IBM Fellowship nominations
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Mar 89 16:13:14 PST
Date: Thu 9 Mar 89 16:09:47-PST
From: Carolyn Tajnai <TAJNAI@Score.Stanford.EDU>
Subject: IBM Fellowship nominations
To: faculty@Score.Stanford.EDU
Message-ID: <12476745461.13.TAJNAI@Score.Stanford.EDU>
CSD will nominate Adam Grove and Pandurang Nayak as new candidates and
Tom Henzinger and Karen Myers for renewals.
8 students were nominated by the faculty, and they are all outstanding.
WE certainly can be proud of our students, and proud to nominate them to
IBM.
Thank you for your cooperation.
Carolyn
-------
∂09-Mar-89 1742 GENESERETH@Score.Stanford.EDU phd admissions
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Mar 89 17:42:27 PST
Date: Thu 9 Mar 89 17:39:05-PST
From: Mike Genesereth <GENESERETH@Score.Stanford.EDU>
Subject: phd admissions
To: faculty@Score.Stanford.EDU
Message-ID: <12476761717.14.GENESERETH@Score.Stanford.EDU>
Folks,
The Admissions committee has done its job. We have offered
admission to the PhD program to 40 people for next fall, and we
would like to get a large number of these admittees to become
acceptors. For this, we need your help. Over the next few weeks,
many of the admittees will be visiting us and will want to
talk with you. (Your fault really. You are the ones who became
famous.) What we ask is that you take the time and make the
effort to help them understand why there is no better department
in the world.
To make your job easier, we have already made some
arrangements. First of all, we are asking that admittees TRY to
schedule their visits more or less in a clump (for the week of
the 19th of March). This means that you won't have lots
of stragglers wandering into your offices at random times for
weeks on end. Secondly, we have asked Nils to talk to these
guys and give them an overview of the departtment and we are
asking the area spokesmen to talk with them and provide
area overviews. Thirdly, we are arranging for grad students
to host the visitors when they arrive and give them a sense
of student life here.
This leaves you folks with the sole task of talking about your
own research and, of course, exercising your charismas. Please
spend a few minutes thinking about how best to present your
own research and please, please take the time to meet with these
people when they arrive. Their student guides will set up the
meetings. Thanks.
mrg
-------
∂09-Mar-89 1847 animal@Portia.stanford.edu Re: SSP Internship lunch
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Mar 89 18:47:16 PST
Received: from Portia.stanford.edu by russell.Stanford.EDU (4.0/inc-1.0)
id AA29050; Thu, 9 Mar 89 18:48:31 PST
Received: by Portia.stanford.edu (5.59/25-eef) id AA11253; Thu, 9 Mar 89 18:43:24 PDT
Date: Thu, 9 Mar 89 18:43:24 PDT
From: Ann Podlozny <animal@Portia.stanford.edu>
Message-Id: <8903100243.AA11253@Portia.stanford.edu>
To: KUDER@CSLI.Stanford.EDU
Cc: ssp-faculty@russell.Stanford.EDU, ssp-students@russell.Stanford.EDU
In-Reply-To: Margie Kuder's message of Thu 9 Mar 89 11:23:21-PST <605474601.0.KUDER@CSLI.Stanford.EDU>
Subject: Re: SSP Internship lunch
Yes, I will be attending the luncheon, but my name is Podlozny, not
Podiozny. Minor, but I just thought I'd correct it while I thought of
it.
Thanks!
∂09-Mar-89 1914 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu COLLOQUIUM SERIES 88-89, Marist College
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Mar 89 19:14:17 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA02633; Thu, 9 Mar 89 19:11:46 -0800
Message-Id: <8903100311.AA02633@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Thu, 9 Mar 89 19:13:51 PST
Received: by BYUADMIN (Mailer R2.01A) id 8428; Thu, 09 Mar 89 19:37:59 MST
Date: Thu, 9 Mar 89 12:39:07 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"William J. Joel" <JZEM%MARIST.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "William J. Joel" <JZEM%MARIST.BITNET@forsythe.stanford.edu>
Subject: COLLOQUIUM SERIES 88-89, Marist College
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
COLLOQUIUM SERIES 88-89
Division of Computer Science and Mathematics
Marist College
Poughkeepsie, NY
Title An Introduction to the Field of Human Factors
Speaker Ronald G. Shapiro, Ph.D., IBM Corporation
Date Tuesday, March 14, 1989
Time 1:00 PM - 2:20 PM
Abstract
Human Factors involves designing equipment so that
people will be able to use it safely, accurately, and
rapidly. A competent human factors professional
must, therefore, understand human capacity and limi-
tations as well as the task which needs to be per-
formed.
In the present talk, the need for competent human
factors will be discussed by exploring some of the
more dramatic problems and their solutions as depict-
ed in the history of the discipline. The talk will
continue with a discussion of how human factors
affects each of our lives. Basic Human Factors prin-
ciples and examples will be provided. The talk will
conclude with a discussion of requisite education for
a human factors professional, a human factors techni-
cian, and a human factors consumer.
Dr. Shapiro has served as an adjunct professor at
Marist College teaching a course in Human Factors.
He is a member of the Human Factors Design and Devel-
opment Department at IBM in Poughkeepsie, NY, chair
of the Mid Hudson Association of Engineering and Sci-
entific Societies, program chair of the Hudson Valley
Chapter of the Human Factors Society, and IBM's rep-
resentative to the SHARE, Inc. Human Factors project.
Dr. Shapiro received his Ph.D. and M.A. in Experimen-
tal Psychology from Ohio State University and his
B.A. in Psychology from the University of Rochester.
Refreshments will be served.
∂09-Mar-89 2038 LOGMTC-mailer "Categories for the working logician"
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Mar 89 20:37:58 PST
Received: by csli.Stanford.EDU (4.0/inc-1.0)
id AA28191; Thu, 9 Mar 89 20:35:49 PST
Date: Thu 9 Mar 89 20:35:49-PST
From: Sol Feferman <SF@CSLI.Stanford.EDU>
Subject: "Categories for the working logician"
To: Logic@csli.Stanford.EDU
Message-Id: <605507749.0.SF@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
Course, Spring 1989, Topics in Logic (Math.294, = Phil.394)
"Categories for the working logician"
MW 4:15-5:30, Rooms 381-T (M), 383-N (W)
First meeting, Wed. April 4
Topics:
1.Review of basic notions and examples (categories, universals and limits,
functors, natural transformations, adjoint functors).
2.Topoi and sheaf models for intuitionistic and higher-order theories.
3.Girard's dilators (ordinal functors) and PI-1-2 logic.
4.Foundations of category theory.
How far each topic 2-4 can be pursued will depend on time.
Prerequisites:
Math 290A and 292A or equivalent (model theory and set theory).
Some background reading in category theory is advised.
Recommended introductory sources:
J.Adamek, Theory of mathematical structures.
T.S.Blyth, Categories
H.Herrlich and G.Strecker, Category theory, an introduction
S.Mac Lane, Categories for the working mathematician (the standard reference).
Auditors are welcome.
S. Feferman
-------
∂10-Mar-89 2024 LOGMTC-mailer The Alfred Tarski Lectures
Received: from csli.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Mar 89 20:24:34 PST
Received: by csli.Stanford.EDU (4.0/inc-1.0)
id AA04693; Fri, 10 Mar 89 20:22:24 PST
Date: Fri 10 Mar 89 20:22:23-PST
From: Sol Feferman <SF@CSLI.Stanford.EDU>
Subject: The Alfred Tarski Lectures
To: logic@csli.Stanford.EDU
Message-Id: <605593343.0.SF@CSLI.Stanford.EDU>
Mail-System-Version: <SUN-MM(242)+TOPSLIB(128)@CSLI.Stanford.EDU>
The Alfred Tarski Lectures
Inaugural lectures on
philosophy, mathematics, computer science
Dana Scott
Carnegie-Mellon University
Monday, March 27 at 4PM: "Wherein lies the foundation of mathematics?"
Wednesday, March 29 at 4PM: "How far do we need to automate proofs?"
Friday, March 31 at 4PM: "Can we teach geometry on the computer?"
All lectures in Room 155, Dwinelle Hall, Univ. of California at Berkeley
-------
∂11-Mar-89 1034 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu network meeting announcement for distribution
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Mar 89 10:34:00 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA18325; Sat, 11 Mar 89 10:31:41 -0800
Message-Id: <8903111831.AA18325@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Sat, 11 Mar 89 10:33:46 PST
Received: by BYUADMIN (Mailer R2.01A) id 5555; Sat, 11 Mar 89 11:30:05 MST
Date: Sat, 11 Mar 89 12:24:09 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
Michael Cohen <mike@BUCASB.BU.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: Michael Cohen <mike@BUCASB.BU.EDU>
Subject: network meeting announcement for distribution
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
NEURAL NETWORK MODELS OF CONDITIONING AND ACTION
12th Symposium on Models of Behavior
Friday and Saturday, June 2 and 3, 1989
105 William James Hall, Harvard University
33 Kirkland Street, Cambridge, Massachusetts
PROGRAM COMMITTEE:
Michael Commons, Harvard Medical School
Stephen Grossberg, Boston University
John E.R. Staddon, Duke University
JUNE 2, 8:30AM--11:45AM
-----------------------
Daniel L. Alkon, ``Pattern Recognition and Storage by an Artificial
Network Derived from Biological Systems''
John H. Byrne, ``Analysis and Simulation of Cellular and Network Properties
Contributing to Learning and Memory in Aplysia''
William B. Levy, ``Synaptic Modification Rules in Hippocampal Learning''
JUNE 2, 1:00PM--5:15PM
----------------------
Gail A. Carpenter, ``Recognition Learning by a Hierarchical ART Network
Modulated by Reinforcement Feedback''
Stephen Grossberg, ``Neural Dynamics of Reinforcement Learning, Selective
Attention, and Adaptive Timing''
Daniel S. Levine, ``Simulations of Conditioned Perseveration and Novelty
Preference from Frontal Lobe Damage''
Nestor A. Schmajuk, ``Neural Dynamics of Hippocampal Modulation of Classical
Conditioning''
JUNE 3, 8:30AM--11:45AM
-----------------------
John W. Moore, ``Implementing Connectionist Algorithms for Classical
Conditioning in the Brain''
Russell M. Church, ``A Connectionist Model of Scalar Timing Theory''
William S. Maki, ``Connectionist Approach to Conditional Discrimination:
Learning, Short-Term Memory, and Attention''
JUNE 3, 1:00PM--5:15PM
----------------------
Michael L. Commons, ``Models of Acquisition and Preference''
John E.R. Staddon, ``Simple Parallel Model for Operant Learning with
Application to a Class of Inference Problems''
Alliston K. Reid, ``Computational Models of Instrumental and Scheduled
Performance''
Stephen Jose Hanson, ``Behavioral Diversity, Hypothesis Testing, and
the Stochastic Delta Rule''
Richard S. Sutton, ``Time Derivative Models of Pavlovian Reinforcement''
FOR REGISTRATION INFORMATION SEE ATTACHED OR WRITE:
Dr. Michael L. Commons
Society for Quantitative Analysis of Behavior
234 Huron Avenue
Cambridge, MA 02138
----------------------------------------------------------------------
----------------------------------------------------------------------
REGISTRATION FEE BY MAIL
(Paid by check to Society for Quantitative Analysis of Behavior)
(Postmarked by April 30, 1989)
Name: ______________________________________________
Title: _____________________________________________
Affiliation: _______________________________________
Address: ___________________________________________
Telephone(s): ______________________________________
E-mail address: ____________________________________
( ) Regular $35
( ) Full-time student $25
School ____________________________________________
Graduate Date _____________________________________
Print Faculty Name ________________________________
Faculty Signature _________________________________
PREPAID 10-COURSE CHINESE BANQUET ON JUNE 2
( ) $20 (add to pre-registration fee check)
-----------------------------------------------------------------------------
(cut here and mail with your check to)
Dr. Michael L. Commons
Society for Quantitative Analysis of Behavior
234 Huron Avenue
Cambridge, MA 02138
REGISTRATION FEE AT THE MEETING
( ) Regular $45
( ) Full-time Student $30
(Students must show active student I.D. to receive this rate)
ON SITE REGISTRATION
5:00--8:00PM, June 1, at the RECEPTION in Room 1550, William James Hall,
33 Kirkland Street, and 7:30--8:30AM, June 2, in the LOBBY of William
James Hall.
Registration by mail before April 30, 1989 is recommended
as seating is limited
HOUSING INFORMATION
Rooms have been reserved in the name of the symposium for the Friday
and Saturday nights at:
Best Western Homestead Inn
220 Alewife Brook Parkway
Cambridge, MA 02138
Single: $72
Double: $80
Reserve your room as soon as possible. The hotel will not hold them past
March 31. Because of Harvard and MIT graduation ceremonies, space will
fill up rapidly. Other nearby hotels:
Howard Johnson's Motor Lodge
777 Memorial Drive
Cambridge, MA 02139
(617) 492-7777
(800) 654-2000
Single: $115--$135
Double: $115--$135
Suisse Chalet
211 Concord Turnpike Parkway
Cambridge, MA 02140
(617) 661-7800
(800) 258-1980
Single: $48.70
Double: $52.70
---------------------------------------------------------------------------
∂11-Mar-89 1139 HEMENWAY@Score.Stanford.EDU Ph.D. Admits
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Mar 89 11:39:40 PST
Date: Sat 11 Mar 89 11:35:35-PST
From: Sharon Hemenway <HEMENWAY@Score.Stanford.EDU>
Subject: Ph.D. Admits
To: faculty@Score.Stanford.EDU
Message-ID: <12477219831.11.HEMENWAY@Score.Stanford.EDU>
I've appended below the list of students to whom we have offered
admission to the Ph.D. program for next year. Please don't hesitate
to contact me if you would like any additional information (such as
phone numbers or addresses). The Recruitment committee will be hard
at work arranging visits over the next few weeks. I'm sure that
Andrew Kosoresow (kos@polya) will be willing to serve as a point of
contact between the faculty and the committee so please get in touch
with him if there are particular people you would like to meet.
Sharon
Name Interests Undergraduate School (M.S. School)
Bauer, Romy L APP CG UNIVERSITY OF CALIFORNIA, BERKELEY
Blackston, David T AA VLSI MIT
Blumofe, Robert D AA DA BROWN UNIVERSITY (Same)
Brewer, Eric A VLSI CG UNIVERSITY OF CALIFORNIA, BERKELEY
Chen, Stanley AI DB CALIFORNIA INSTITUTE OF TECHNOLOGY
Cyrluk, David A PSL MTC UNIVERSITY OF PENNSYLVANIA (RPI)
Darwiche, Adnan AI CL KUWAIT UNIVERSITY (Stanford Univ.)
Dellarocas, Chryssanthos PSL AA NATIONAL TECHNICAL UNIVERSITY ATHENS
Doorenbos, Robert B AI MTC UNIVERSITY OF MICHIGAN, ANN ARBOR
Drexler, Andreas J OS GEORG-AUGUST-UNIVERSITAT GOTTINGEN
Garde, Rashmi NDS OS UNIVERSITY OF CALIFORNIA, BERKELEY
Glim, Stephen M PSL DCS PRINCETON UNIVERSITY
Greenwald, Michael B NDS OS MIT
Greiner, John D PSL CL RICE UNIVERSITY
Gupta, Vineet MTC AA INDIAN INSTITUTE OF TECHNOLOGY, KANPUR
Harvey, William D OS NDS STANFORD UNIVERSITY
Hinrichs, Susan K APP PSL UNIV OF ILLINOIS AT URBANA-CHAMPAIGN
Hu, Alan J AA AI STANFORD UNIVERSITY
Jackson, Eric G AI CL HARVARD UNIVERSITY
Karger, David R AA MTC HARVARD UNIVERSITY
Kavraki, Lydia E AI PSL UNIVERSITY OF CRETE
Koller, Daphne NDS DB HEBREW UNIVERSITY OF JERUSALEM (Same)
Laidlaw, David H CG APP BROWN UNIVERSITY (Same)
Lang, Andrew K AI CL DUKE UNIVERSITY
Lee, Mavis K AI APP MIT (Same)
Lee, Michelle K DB AI MIT (Same)
Lipa, William J PSL DB STANFORD UNIVERSITY
Paxson, Vern E PSL CG STANFORD UNIVERSITY
Peck, Virginia A CL AI CORNELL UNIVERSITY
Polimenis, Vassilios G AA MTC UNIVERSITY OF PATRAS
Quinlan, Sean ROB PSL UNIVERSITY OF SYDNEY
Roy, Howard S AI MTC HARVARD UNIVERSITY
Schwartz, Anton L AI MTC HARVARD UNIVERSITY
Singh, Mona AA MTC HARVARD UNIVERSITY (Same)
Thrash, Wendy A PSL DCS MARIETTA COLLEGE (Michigan State)
Torng, Eric K NDS AI PRINCETON UNIVERSITY
Torres, Alberto AI AA UNIVERSIDAD SIMON BOLIVAR (Same)
Waarts, Orli NDS AA TECHNION (WEIZMANN INSTITUTE OF SCIENCE)
Wald, David E PSL MTC YALE UNIVERSITY (Same)
Williamson, David P MTC AA MIT
Deferral from 1988-89:
Haimowitz, Ira AI CL MIT (Cambridge University)
-------
∂12-Mar-89 1616 X3J13-mailer Issue: UNSOLICITED-MESSAGES
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Mar 89 16:16:40 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 555408; Sun 12-Mar-89 19:14:06 EST
Date: Sun, 12 Mar 89 19:13 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: UNSOLICITED-MESSAGES
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu
In-Reply-To: <8902242237.AA14750@decwrl.dec.com>
Message-ID: <890312191349.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
I agree that this is an important issue.
I am not sure I agree with the proposed solution -- partly because
I don't think it goes nearly far enough, and partly because I think the
wording for the place where it stops encourages might actually encourage
more `abuse' than currently exists.
I think it should be possible to know with certainly that calling EQ,
CONS, or even COMPILE, was not going to do I/O, at least in
the normal case. In exceptional cases, CONS might produce GC warnings
or COMPILE might produce compiler warnings, but never should COMPILE
type out anything like
Compiling FOO.
or should EQ type out
Performing EQ comparison of #<FOO 32> and #<BAR 17>.
Right now, nothing assures me of this and I find that disturbing.
This is the issue which I expected to `fix' this problem, and it does
not. In fact, its suggestion that it's ok to type such messages on
*TERMINAL-IO* may actually encourage what I consider to be an abominable
practice.
I would like it stated clearly that in the `normal situation' no
LISP function is permitted to do I/O unless the manual expressly
permits it.
Further, I think the current proposal permitting unsolicited messages
to go to *TERMINAL-IO* is a bad idea. I don't think unsolicited messages
should ever go directly to *TERMINAL-IO*. I am ammenable to them going to
documented streams which happen to have initial values that are synonym
streams to *TERMINAL-IO*, but
- I -don't- want them to be the standard CL streams, so I don't redirect
them by accident.
- I -do- want them to not be *terminal-io* so I can redirect them on
purpose.
Conceivably we could actually make a *JUNK-OUTPUT* which is initially a
synonym stream to *TERMINAL-IO*, but which is specially permitted to be
NIL to mean don't send the output anywhere, and we should say that all
unsolicited I/O has to go through there.
∂13-Mar-89 0714 X3J13-mailer cl-compiler mail
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 07:14:10 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA16287; Mon, 13 Mar 89 08:12:01 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02044; Mon, 13 Mar 89 08:11:59 -0700
Date: Mon, 13 Mar 89 08:11:59 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131511.AA02044@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: cl-compiler mail
I will be sending out the remaining batch of cl-compiler issues today.
I will also put FTP'able copies on host cs.utah.edu in directory
~ftp/pub/cl-compiler/pending. I'll send out a summary of issues when
I've gotten through them all.
It may be necessary for us to bring revised versions of some of these
proposals to the meeting. In particular, a few of them have been put
together at the last minute and haven't been reviewed thoroughly yet;
I've marked these as drafts so you'll be able to identify them. Any
comments or questions should be directed to cl-compiler@sail.stanford.edu.
-Sandra
∂13-Mar-89 0747 X3J13-mailer issue COMPILED-FUNCTION-REQUIREMENTS, version 4
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 07:47:01 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA17004; Mon, 13 Mar 89 08:44:52 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02070; Mon, 13 Mar 89 08:44:48 -0700
Date: Mon, 13 Mar 89 08:44:48 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131544.AA02070@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
Forum: Compiler
Issue: COMPILED-FUNCTION-REQUIREMENTS
References: CLtL p. 32, 76, 112, 143, 438-439
Issue FUNCTION-TYPE (passed)
Issue COMPILER-LET-CONFUSION
Issue EVAL-WHEN-NON-TOP-LEVEL
Issue LOAD-TIME-EVAL (passed)
Issue COMPILE-ENVIRONMENT-CONSISTENCY
Category: CLARIFICATION
Edit History: V1, 3 Jan 1989 Sandra Loosemore
V2, 10 Jan 1989, Sandra Loosemore (additional proposal)
V3, 10 Feb 1989, Sandra Loosemore (new proposal)
V4, 11 Mar 1989, Sandra Loosemore (fix wording to agree
with other pending proposals)
Status: Ready for release
Problem Description:
There is confusion about what functions might be or must be of type
COMPILED-FUNCTION, and what attributes must be true of
COMPILED-FUNCTIONs. Is the distinction between COMPILED-FUNCTIONs and
other functions only one of representation, or can user programs infer
anything about COMPILED-FUNCTIONs? Are implementations required to
distinguish between compiled and non-compiled functions?
CLtL defines a COMPILED-FUNCTION as "a compiled code object". (Issue
FUNCTION-TYPE says only that COMPILED-FUNCTION must be a subtype of
FUNCTION.) Although it is not explicitly stated, CLtL implies that
compiled code must conform to certain rules; in particular, it states
that all macros are expanded at compile time, and specifies different
behavior for the COMPILER-LET and the EVAL-WHEN special forms
depending on whether they are interpreted or compiled.
The description of COMPILE in CLtL says that "a compiled-function object
[is] produced". It is not clear to everyone whether this implies that
COMPILED-FUNCTION-P must be true of such functions. CLtL says nothing
about whether functions defined in files compiled with COMPILE-FILE and
subsequently loaded must be of type COMPILED-FUNCTION.
The two proposals presented below present a simple model of the
compilation process. A minimal compiler could be implemented to
perform a code walk to apply the indicated transformations to the
function source code. Of course, most compilers will perform other
transformations as well, such as translating the Lisp source code into
a representation that is more compact or which can be executed more
efficiently.
Proposal COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN:
(1) Clarify that if a function is of type COMPILED-FUNCTION, the
following are guaranteed about the function:
- All macro calls appearing lexically within the function have
already been expanded and will not be expanded again when the
function is called. (See CLtL p. 143.) The process of
compilation effectively turns MACROLET and SYMBOL-MACROLET
constructs into PROGNs with all instances of the local macros
in the body fully expanded.
- The compiler must capture declarations to determine whether
variable bindings and references appearing lexically within
the function are to be treated as lexical or special.
- COMPILER-LETs nested lexically within the function will not bind
any variables when the function is called (CLtL p. 112). Again,
the process of compilation effectively turns COMPILER-LET
constructs into PROGNs with all macros in the body fully expanded.
- Lexically nested EVAL-WHENs have been processed as stated in
proposal EVAL-WHEN-NON-TOP-LEVEL; either the body is treated as
an implicit PROGN or as the constant NIL.
- If the function contains lexically nested LOAD-TIME-VALUE forms,
these have already been pre-evaluated and will not be evaluated
again when the function is called.
(2) Implementations are free to classify all functions as
COMPILED-FUNCTIONs, provided that all functions satisfy the criteria
listed in item (1). It is also permissible for functions that are
not COMPILED-FUNCTIONs to satisfy the above criteria.
(3) Clarify that COMPILE always produces an object of type
COMPILED-FUNCTION. Clarify when functions are defined in a
file which is compiled with COMPILE-FILE, and the compiled file is
subsequently LOADed, objects of type COMPILED-FUNCTION result.
Rationale:
This proposal allows users to count on COMPILE and COMPILE-FILE always
producing objects that are COMPILED-FUNCTION-P.
It assigns some specific properties to compiled functions. Users would
be able to rely on any function which is of type COMPILED-FUNCTION having
really been (at least partially) compiled.
It also states what many people believe to be the minimum functionality
required of a compiler.
Proposal COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN-COMPILE:
(1) Clarify that functions produced by COMPILE, or defined in a file
produced by COMPILE-FILE which has been subsequently LOADed, must
satisfy the same requirements listed in section (1) of proposal
TIGHTEN.
(2) Clarify that COMPILE always produces an object of type
COMPILED-FUNCTION. Clarify when functions are defined in a
file which is compiled with COMPILE-FILE, and the compiled file is
subsequently LOADed, objects of type COMPILED-FUNCTION result.
Rationale:
This proposal allows users to count on COMPILE and COMPILE-FILE always
producing objects that are COMPILED-FUNCTION-P.
It also states what many people believe to be the minimum functionality
required of a compiler.
However, it allows functions that have not been compiled also to be of
type COMPILED-FUNCTION. For implementations that do not use different
representations for interpreted and compiled functions, it would still
allow COMPILED-FUNCTION and FUNCTION to be synonymous, even if
interpreted functions do not satisfy the requirements for compilation.
Current Practice:
It appears that most implementations currently distinguish compiled
versus non-compiled functions on the basis of representation. It seems
unlikely that any implementation would have problems satisfying the
stated minimum requirements for compilation.
Lucid uses the same representation for both compiled and non-compiled
functions, except there is a bit in the header used to distinguish them.
A-Lisp uses the same representation for both compiled and interpreted
functions and currently labels them both as COMPILED-FUNCTION, but the
implementation of COMPILED-FUNCTION-P could be easily fixed to
distinguish "real" compiled functions.
On the TI Explorer, the COMPILE function can return an object of
either type COMPILED-FUNCTION or LEXICAL-CLOSURE, where the latter
consists of two components -- an environment and a COMPILED-FUNCTION.
There is confusion about whether microcoded functions should be
considered compiled or not.
Cost to implementors:
Unknown, but probably small for either proposal. Proposal
TIGHTEN-COMPILE is probably most consistent with current practice.
Cost to users:
Probably minimal. Since the COMPILED-FUNCTION type specifier is
currently ill-defined, it is hard to imagine that existing programs
can portably rely on any interpretation of what it means that is
inconsistent with what is presented here.
Benefits:
The specification of what the compiler must do is made more explicit.
Discussion:
The FIXNUM and BIGNUM types were also defined in CLtL solely on the
basis of distinguished representations, and that this definition has
proved inadequate for just about all portable usages of these type
specifiers. Defining COMPILED-FUNCTION solely on the basis of
distinguished representation seems like a bad idea.
David Gray notes:
We make good use of the type COMPILED-FUNCTION in our implementation,
but all of the accessor functions for objects of that type are
non-standard, which makes me wonder if it might be best to just remove
this type from the standard along with BIGNUM.
One use of the COMPILED-FUNCTION type is in declarations. A-Lisp and
Lucid, for example, can compile FUNCALL more efficiently if it can be
determined that the function is of type COMPILED-FUNCTION. However,
in order for such declarations to be really useful, there should be a
way to construct an object which is guaranteed to be of type
COMPILED-FUNCTION. Both of the proposals presented require COMPILE
and COMPILE-FILE to construct compiled functions.
Sandra Loosemore says:
I have a marginal preference for proposal TIGHTEN-COMPILE, since it
gives implementors more flexibility. To me it's more important that
COMPILE and COMPILE-FILE be guaranteed to do something, than that I
be able to test whether a function has had those things done to it.
∂13-Mar-89 0748 X3J13-mailer issue COMPILER-DIAGNOSTICS, version 9
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 07:48:14 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA17028; Mon, 13 Mar 89 08:46:02 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02075; Mon, 13 Mar 89 08:45:59 -0700
Date: Mon, 13 Mar 89 08:45:59 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131545.AA02075@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue COMPILER-DIAGNOSTICS, version 9
Forum: Compiler
Issue: COMPILER-DIAGNOSTICS
References: CLtL p. 438-439, 62, 69, 160, 161
Condition System, Revision #18
S:>KMP>cl-conditions.text.34
Issue GC-MESSAGES
Issue RETURN-VALUES-UNSPECIFIED
Issue COMPILER-VERBOSITY
Category: CLARIFICATION, ENHANCEMENT
Edit History: V1, 15 Oct 1988, Sandra Loosemore
V2, 19 Oct 1988, Sandra Loosemore (minor fixes)
V3, 25 Oct 1988, Sandra Loosemore (input from Pitman & Gray)
V4, 01 Nov 1988, Sandra Loosemore (fix typos)
V5, 15 Dec 1988, Dan L. Pierson (new condition types)
V6, 15 Dec 1988, Sandra Loosemore (additions, fix wording)
V7, 16 Dec 1988, Dan L. Pierson (minor cleanup)
V8, 07 Jan 1989, Sandra Loosemore (expand discussion)
V9, 26 Jan 1989, Sandra Loosemore (simplify)
Status: Ready for release
Problem Description:
It is unclear whether various diagnostics issued by the compiler are
supposed to be true errors and warnings, or merely messages.
In some implementations, COMPILE-FILE handles even serious error
situations (such as syntax errors) by printing a message and then
trying to recover and continue compiling the rest of the file, rather
than by signalling an error. While this user interface style is just
as acceptable as invoking the debugger, it means that a normal return
from COMPILE-FILE does not necessarily imply that the file was
successfully compiled.
Many compilers issue warnings about programming style issues (such as
binding a variable that is never used but not declared IGNORE).
Sometimes these messages obscure warnings about more serious problems,
and there should be some way to differentiate between the two. For
example, it should be possible to suppress the style warnings.
Also, neither CLtL nor issue RETURN-VALUES-UNSPECIFIED states what the
return value from COMPILE-FILE should be.
Proposal COMPILER-DIAGNOSTICS:USE-HANDLER:
(1) Introduce a new condition type, STYLE-WARNING, which is a subtype
of WARNING.
(2) Clarify that ERROR and WARNING conditions may be signalled within
COMPILE or COMPILE-FILE, including arbitrary errors which may
occur due to compile-time processing of (EVAL-WHEN (COMPILE) ...)
forms or macro expansion.
Considering only those conditions signalled -by- the compiler (as
opposed to -within- the compiler),
(a) Conditions of type ERROR may be signalled by the compiler in
situations where the compilation cannot proceed without
intervention.
Examples:
file open errors
syntax errors
(b) Conditions of type WARNING may be signalled by the compiler in
situations where the standard explicitly states that a warning must,
should, or may be signalled; and where the compiler can determine
that a situation that "is an error" would result at runtime.
Examples:
violation of type declarations
SETQ'ing or rebinding a constant defined with DEFCONSTANT
calls to built-in Lisp functions with wrong number of arguments
or malformed keyword argument lists
referencing a variable declared IGNORE
unrecognized declaration specifiers
(c) The compiler is permitted to signal diagnostics about matters of
programming style as conditions of type STYLE-WARNING. Although
STYLE-WARNINGs -may- be signalled in these situations, no
implementation is -required- to do so. However, if an
implementation does choose to signal a condition, that condition
will be of type STYLE-WARNING and will be signalled by a call to
the function WARN.
Examples:
redefinition of function with different argument list
unreferenced local variables not declared IGNORE
declaration specifiers described in CLtL but ignored by
the compiler
(3) Require COMPILE and COMPILE-FILE to handle the ABORT restart by
aborting the smallest feasible part of the compilation. State that
both COMPILE and COMPILE-FILE are allowed to establish a default
condition handler. If such a condition handler is established,
however, it must first resignal the condition to give any
user-established handlers a chance to handle it. If all user error
handlers decline, the default handler may handle the condition in an
implementation-specific way; for example, it might turn errors into
warnings.
(4) Specify that COMPILE-FILE returns two values. The first value
is the truename of the output file, or NIL if the file could not be
created. The second value is T if the file was compiled without
errors, or NIL if errors were signalled during compilation.
Rationale:
Introducing the STYLE-WARNING condition allows handlers to distinguish
between potentially serious problems and mere kibitzing on the part of
the compiler.
Requiring any condition handlers established by the compiler to resignal
the condition before proceeding with any implementation-specific action
gives user error handlers a chance to override the compiler's default
behavior. For example, the user error handler could invoke a restart
such as ABORT or MUFFLE-WARNING.
Requiring the compiler to handle the ABORT restart reflects what
several implementations already do (although probably not using this
mechanism). The intent of the wording is to allow an implementation
to abort the entire compilation if it is not feasible to abort a
smaller part.
Requiring a second success-p value to be returned from COMPILE-FILE
gives the user some indication of whether there were serious problems
encountered in compiling the file.
Test Case/Example:
Here is an example of how COMPILE-FILE might set up its condition
handlers. It establishes an ABORT restart to abort the compilation
and a handler to take implementation-specific action on ERROR
conditions. Note that INTERNAL-COMPILE-FILE may set up additional
ABORT restarts.
(defvar *output-file-truename* nil)
(defun compile-file (input-file &key output-file)
(let ((*output-file-truename* nil)
(errors-detected nil))
(with-simple-restart (abort "Abort compilation.")
(handler-bind ((error #'(lambda (condition)
(setq errors-detected t)
(signal condition)
...)))
(internal-compile-file input-file output-file)))
(values *output-file-truename*
errors-detected)))
Current Practice:
No implementation behaves exactly as specified in this proposal.
In VaxLisp, COMPILE-FILE handles most compile-time errors without
invoking the debugger. (It gives up on that top-level form and moves on
to the next one.) Instead of signalling errors or warnings, it simply
prints them out as messages.
In Lucid Common Lisp, COMPILE-FILE invokes the debugger when it encounters
serious problems. COMPILE-FILE returns the pathname for the output file.
Symbolics Genera usually tries to keep compiling when it encounters errors;
so does Symbolics Cloe.
On the TI Explorer, the compiler tries to catch most errors and turn
them into warnings (except for errors on opening a file), but the user
can change special variable COMPILER:WARN-ON-ERRORS to NIL if he wants
to enter the debugger on an error signalled during reading, macro
expansion, or compile-time evaluation. The true name of the output
file is returned as the first value. A second value indicates whether
any errors or warnings were reported.
IIM Common Lisp's compiler handles errors using a resignalling mechanism
similar to what is described here.
Cost to implementors:
The cost to implementors is not trivial but not particularly high. This
proposal tries to allow implementations considerable freedom in what
kinds of conditions the compiler must detect and how they are handled,
while still allowing users some reasonably portable ways to deal with
compile-time errors.
Cost to users:
This is a compatible extension. This proposal may cause users to see
some small differences in the user interface to the compiler, but
implementations already vary quite widely in their approaches. Some
users will probably have to make some minor changes to their code.
Adding the STYLE-WARNING type may cause conflicts with programs
already using that name.
Benefits:
Users are given a way to detect and handle compilation errors, which
would simplify the implementation of portable code-maintenance
utilities. The behavior of the compiler in error situations is made
more uniform across implementations.
Discussion:
The issue of whether the compiler may print normal progress messages
is discussed in detail in a separate issue, COMPILER-VERBOSITY.
∂13-Mar-89 0749 X3J13-mailer issue COMPILER-VERBOSITY, version 6
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 07:48:54 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA17056; Mon, 13 Mar 89 08:46:44 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02078; Mon, 13 Mar 89 08:46:42 -0700
Date: Mon, 13 Mar 89 08:46:42 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131546.AA02078@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue COMPILER-VERBOSITY, version 6
Forum: Compiler
Issue: COMPILER-VERBOSITY
References: CLtL p. 438-329; 426
issue COMPILER-DIAGNOSTICS
Category: ENHANCEMENT
Edit History: V1, 25 Oct 1988, Sandra Loosemore
V2, 12 Dec 1988, Dan L. Pierson (add USE-CONDITIONS)
V3, 15 Dec 1988, Dan L. Pierson (expand on conditions)
V4, 21 Dec 1988, Dan L. Pierson (reword and clarify)
V5, 06 Jan 1989, Sandra Loosemore (update discussion)
V6, 26 Jan 1989, Sandra Loosemore (remove USE-CONDITIONS)
Status: Ready for release
Problem Description:
Implementations vary widely in the amount of information that is printed
out by COMPILE-FILE. In some situations, it would be useful to control
how much information is printed.
Proposal COMPILER-VERBOSITY:LIKE-LOAD:
Introduce special variables, *COMPILE-VERBOSE* and *COMPILE-PRINT*,
with implementation-dependent initial values.
Add :VERBOSE and :PRINT keyword arguments to the function
COMPILE-FILE, analogous to those for the function LOAD.
The :VERBOSE argument (which defaults to the value of
*COMPILE-VERBOSE*), if true, permits COMPILE-FILE to print a message
in the form of a comment to *STANDARD-OUTPUT* indicating what file is
being compiled and other useful information.
The :PRINT argument (which defaults to the value of *COMPILE-PRINT*),
if true, causes information about top-level forms in the file being
compiled to be printed to *STANDARD-OUTPUT*. Exactly what is printed
will vary from implementation to implementation, but nevertheless some
information will be printed.
Introduce a special variable *LOAD-PRINT*, which has an initial value of
NIL. State that the default value of the :PRINT argument to LOAD is
*LOAD-PRINT* (rather than NIL).
Rationale:
This proposal makes COMPILE-FILE behave like LOAD. There is already
some precedent for doing this (for example, issue COMPILE-FILE-PACKAGE,
which makes COMPILE-FILE as well as LOAD rebind *PACKAGE*).
Adding the *LOAD-PRINT* variable allows the printing of messages by
LOAD to be controlled either on a global or a per-call basis.
Current Practice:
COMPILE-FILE prints out progress messages in nearly all
implementations.
Lucid provides a :MESSAGES keyword argument to COMPILE-FILE, which can
either be a stream to send messages to, or NIL to suppress messages.
The default value is T, which sends messages to "the standard terminal
device".
On the TI Explorer, COMPILE-FILE displays the name of the function
being compiled when the option :VERBOSE T is given or special variable
COMPILER:COMPILER-VERBOSE is true. (In other words, they use :VERBOSE
to mean what this proposal says to use :PRINT for.)
Symbolics Cloe already has a *LOAD-PRINT* variable.
Cost to implementors:
This is an incompatible change for some implementations. While the
changes required should be conceptually simple, their implementation
may involve a significant amount of grunt work. At least two
implementations already provide some similar mechanism for suppressing
messages.
Cost to users:
Some (non-portable) user code may break in implementations where this
is an incompatible change.
No user code should be broken by the addition of the *LOAD-PRINT*
variable, since the default behavior for the :PRINT keyword to LOAD
is unchanged.
Benefits:
Users are given a portable way to control how much information is printed
by COMPILE-FILE.
Discussion:
This issue addresses an extension to the language. If this proposal
is not accepted, the standard will simply continue not to say anything
about whether COMPILE-FILE can print progress messages, or what stream
such messages are directed to.
∂13-Mar-89 0815 X3J13-mailer issue CONSTANT-COMPILABLE-TYPES, version 8
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 08:15:04 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA17983; Mon, 13 Mar 89 09:12:55 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02083; Mon, 13 Mar 89 09:12:49 -0700
Date: Mon, 13 Mar 89 09:12:49 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131612.AA02083@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue CONSTANT-COMPILABLE-TYPES, version 8
Forum: Compiler
Issue: CONSTANT-COMPILABLE-TYPES
References: CLtL pp. 56, 77-80, 324
Issue CONSTANT-MODIFICATION
Issue CONSTANT-CIRCULAR-COMPILATION
Issue CONSTANT-ARRAY-ATTRIBUTES
Issue QUOTE-SEMANTICS
Issue LOAD-OBJECTS
Category: CLARIFICATION, ADDITION
Edit history: 11/07/88, V1 by Cris Perdue
11/14/88, V2 by Cris Perdue
11/22/88, V3 by Cris Perdue
12/20/88, V4 by Cris Perdue
01/06/89, V5 by Sandra Loosemore (minor editorial
clarifications, expand discussion)
03/05/89, V6 by Cris Perdue (more response to comments,
especially from Moon and and from Loosemore)
03/05/89, V7 by Loosemore (more editorial tweaks)
03/13/89, V8 by Loosemore (discussion)
Status: Ready for release
Problem description:
CLtL does not specify what objects can be in compiled constants and it
does not say what relationship there is to be between the
constant passed to the compiler and the one that is established by
compiling and then loading its file. Relevant remarks in CLtL
concerning file compilation and the definition of QUOTE suggest that
the compiler handles constants in ways that are not actually possible.
Introduction to the proposal:
The proposal CONSTANT-COMPILABLE-TYPES:SPECIFY attempts to spell out
what types can appear in compiled constants, and what it means when
they appear. Unless stated otherwise, in this proposal where the term
"constant" is used, it means a quoted or self-evaluating constant, not
a named (defconstant) constant.
The key is a definition of a form of equivalence between Lisp objects,
"similarity as constants". Code passed through the file compiler and
then loaded must behave as though quoted constants in it are "similar"
to quoted constants in the corresponding interpreted "source" code.
Because it is legitimate to compile in one address space and load into
a different one, it is necessary for the constraints to be defined
across address spaces. This proposal only concerns quoted constants
to be processed by COMPILE-FILE. Some other issues related to file
compilation are CONSTANT-COLLAPSING, CONSTANT-CIRCULAR-COMPILATION,
and QUOTE-SEMANTICS.
Some implementations "lose information" about some constants during
compilation. Typically all constant arrays become simple arrays
during the process of compiling and loading. We try to balance the
desire for more functionality against the effort required from
implementors.
Comments within the text of the proposal are enclosed in double angle
brackets, <<like this>>.
Proposal: CONSTANT-COMPILABLE-TYPES:SPECIFY
An object may be used as a quoted constant processed by COMPILE-FILE
if the compiler can guarantee that the resulting constant established
by loading the compiled file is "similar as a constant" to the
original. Treatment of uninterned symbols must be consistent across
the entire file as described below. There also is a constraint on
arrays which is not symmetrical; compilation can make arrays
"simpler", but not "less simple". (See below for the definition.)
We refer below to "quoted constants" or just "constants". In this
section these terms refer to objects appearing in expressions of the
form (QUOTE <object>), to objects used as self-evaluating forms, and
to objects appearing in code at locations described as "not
evaluated".
Some types such as streams are not supported in constants. Put
another way, an object containing one of these is not considered
similar as a constant to any other object. Some implementations may
support them and define how they are treated. For any object that
appears in a constant, but is not supported by the language as part of
a constant, the behavior of the compiler is unspecified; either the
the compiler and/or loader will handle that constant (in an
implementation-dependent manner) or the compiler will detect the
situation and signal an error.
Of the types supported in constants, some are treated as aggregate
objects. For these types, being similar as constants is defined
recursively. We say that an object of these types has certain
attributes, and to be similar as a constant to another object, the
values of the corresponding attributes of the two objects must also be
similar as constants.
This kind of definition has problems with any circular or "infinitely
recursive" object such as a list that is an element of itself. We
use the idea of depth-limited comparison, and say that two
objects are similar as constants if they are similar at all finite
levels. This idea is implicit in the definitions below, and applies
in all the places where attributes of two objects are required to be
similar as constants.
Here we define the notion of two objects being "similar as constants",
organizing the definition by type, and note additional constraints
that the compiler and loader working together must meet:
Number
If either of the two objects is a number, both must be of the same
type and must represent the same mathematical value.
Character
If either of the two objects is a character, both must be character
objects that represent the same character. <<Note that this
definition has to depend on the results of the Character Set
proposals.>>
Random-state
Let us say that two random-states are functionally equivalent if
applying RANDOM to them repeatedly always produces the same
pseudo-random numbers in the same order.
Two random-states are similar as constants exactly if copies of them
made via MAKE-RANDOM-STATE are functionally equivalent.
Note that a constant random-state object cannot be used as the "state"
argument to the function RANDOM (because RANDOM side-effects this
data structure).
Symbol
A symbol can only be similar to a symbol. References to interned
symbols are "by name". <<See issue COMPILE-FILE-SYMBOL-HANDLING for
details.>>
If a symbol is not interned, i.e. its home package is NIL, it is
treated in a rather special way. To be similar as a constant to
another symbol, both symbols must be uninterned and have the same
name.
Constants that contain uninterned symbols have to satisfy an extra
constraint. Consider the set of places in a constant that refer to
the same (EQ) uninterned symbol. In any similar constant, the
corresponding places must also all be EQ -- no more places and no
fewer. Moreover, COMPILE-FILE must arrange for the EQness of all
constant uninterned symbols that appear in the file to be preserved,
even if they are referenced in separate constants.
Because hash keys can be aggregate objects and because we treat hash
tables as unordered sets of <key, value> pairs, similarity of hash
tables is more complex. See under "Hash Tables", below, for the
definition.
Package
A package can only be similar as a constant to a package. References
to packages are permitted in any constant. References to packages are
"by name": two packages are similar as constants when their names are
similar as constants. Within a Lisp "address space", packages with
the same name are EQ.
At load time, the package becomes the same as returned by
FIND-PACKAGE, given the package name. An error is signalled if no
package of that name exists at load time.
AGGREGATE TYPES
---------------
For each of the types listed below, if either object is of the given
type, the two objects are similar as constants exactly if the other is
of that type and the values of all of the specified attributes are
similar as constants.
The attributes listed here can be called the "Basic Attributes" of
objects of each of these types.
Cons CAR, CDR.
Array For 1-dimensional arrays:
LENGTH, ARRAY-ELEMENT-TYPE, and ELT for all legal indices.
For arrays of other dimensions:
ARRAY-DIMENSIONS, ARRAY-ELEMENT-TYPE, AREF for all legal
indices.
An array of type SIMPLE-ARRAY can only be similar as a
constant to an array of type SIMPLE-ARRAY. However, we
allow the file-compiler a bit of latitude here. Where
constants in source code are displaced, have fill
pointers, or are adjustable, constants in the code
resulting from compilation and loading are permitted to
lack any or all of these qualities.
Hash Table Keys and value pairs. The table's test is unchanged
also. If the file compiler is given a constant containing a
a hash table that has keys that are similar as
constants, the consequences are undefined.
Consider a hash table as an unordered set of key and
value pairs. Two hash tables are similar as constants
exactly if there is a one-to-one correspondence between
the key and value pairs of each and a one-to-one
correspondence between the uninterned symbols of each
such that the two keys of each corresponding pair are
similar as constants and the two values are also similar
as constants. The correspondence of uninterned symbols
must be consistent with the correspondence defined for
the entire set of constants in the file.
Pathname Each pathname component.
OTHER TYPES
-----------
Stream, Compiled-Function, Readtable, Generic-function, Method
Objects of these types are not supported in compiled
constants.
Function Only function constants that are not compiled-functions
and do not close over any (lexical) variables are
supported in compiled constants.
Two such functions are similar as constants if their
SOURCE-LAMBDA-EXPRESSIONs are similar as constants.
Structure, Standard-object
<<There is a cl-cleanup issue, LOAD-OBJECTS, pending
which proposes a mechanism for dealing with objects.>>
For structure instances with no method defined at compile
time for MAKE-LOAD-FORM, the slot values and the name of
structure type (a symbol reference) are recorded by the
compiler and reconstructed by the loader.
Examples:
If source code contains a constant that could PRINT as (#1=#:FOO
#2=#:FOO #1# #2#), the constant resulting from compiling and loading
that code would have to be PRINTable as (#1=#:FOO #2=#:FOO #1# #2#).
If we make a hash table H, set three variables A, B, and C to
different uninterned symbols named FOO, and enter keys and values as
follows:
(setf (gethash a h) b)
(setf (gethash b h) a)
(setf (gethash c h) c)
If H appears in a compiled constant, after compiling and loading it,
(let ((value (list)))
(maphash #'(lambda (x y) (push (list x y) value)) h)
value)
could print as
((#1=#:FOO #2=#:FOO) (#2# #1#) (#3=#:FOO #3#))
but not as
((#1=#:FOO #2=#:FOO) (#2# #3=#:FOO) (#3# #1#))
Rationale:
For the benefit of users, this proposal tries to define a fairly large
set of types that all Common Lisp implementations are to handle. It
also attempts to leave room for implementations to differ. Some
implementations have made opposing choices because the language
doesn't specify one over the other. Some implementations already
handle constants that this proposal defines as not legal in Common
Lisp programs, and that is useful to users of those systems.
Different implementors have different amounts of resources to apply to
their system, and implementations differ in their whole approach in
some cases.
This proposal appears to reflect user demand and appears not to exceed
the capabilities of most implementations of the language.
The proposal ensures that all references to the same uninterned symbol
within a file will all map to references to just one uninterned symbol
after compiling and loading. This is needed to support PCL.
Current practice:
>From Gail Zacharias (Nov 14): "Coral pretty much implements this
proposal (I think we currently coalesce hash table keys, but that's
just a bug that will be fixed). We also fasdump packages (using the
package name) and compiled functions (but not foreign functions). For
symbols, we dump the name, and if (roughly speaking) the symbol would
get printed with a package prefix, we also dump the package name and
load the symbol into that package (otherwise it gets loaded into the
current load-time package)."
>From David Gray (Nov 9): "The Explorer can compile constant functions,
read tables, and hash tables; an error is signalled for a stream. A
package object used to break the compiler but in release 5 it has been
fixed to generate instructions to call FIND-PACKAGE on the package
name at load time." (Nov 15): [The Explorer does not guarantee
retention of displaced-to and displaced-index-offset attributes.]
"The Explorer also does not currently support dumping closures (either
compiled or evaluated), although non-closure compiled functions can be
dumped."
>From David Moon (Jan 24): "Symbolics Genera current practice: aside
from some current bugs we have with circular structures of certain
types and with preserving the identity of CONSes under EQ, this is
more or less consistent with our current practice, if you made the
changes implied by my earlier comments. We preserve the :displaced-to
and :fill-pointer array attributes. I doubt that we do what the
proposal says for hash-tables, readtables, and random-states. We
support dumping compiled and interpreted functions, but not closures,
which in effect means we don't support dumping functions."
>From Sandra Loosemore (Mar 3): "UCL currently can handle only
constants that are of type number, character, symbol, cons,
simple-vector, or string (which it turns into simple-string). It
signals an error if an attempt is made to compile any other kind of
object as a constant."
Adoption cost:
Not known. Probably moderate or low -- for most implementations. The
cost would be to implementors rather than users since this part of the
language is currently underspecified. The author believes the cost
will be reasonable for KCL, an implementation where there is some
concern about this issue.
This proposal is close to compatible with the Franz, Lucid, Coral,
Texas Instruments, and Symbolics implementations. It is probably
compatible or nearly compatible with other "Lisp Machine"
implementations.
Benefits:
Users would be able to use aggregate objects in constants with
confidence about the behavior of their code.
Conversion cost:
Where this proposal *requires* different behavior than an existing
implementation, there is a conversion cost for users of that
implementation. It appears that this cost will be small, less than
the cost of leaving things unspecified.
Esthetics:
Since there is no adequate definition at present, a fuller definition
would be more esthetic.
Discussion:
This proposal does leave some user-visible attributes of objects
unspecified across the compile-and-load process, except that they must
be consistent with the attributes that must be retained. This
situation is a compromise between the desire for full specification on
the one hand, and on the other hand the desire to leave freedom for
different implementations to remain different and to support some
optimizations such as compacting hash tables and "simplifying" arrays.
Proposals will be entertained for tighter specification of datatypes
such as arrays.
The full extension of the concept of coalescing of constants is to say
that they can be coalesced exactly when they are similar as constants.
Comparing functions semantically is intertwined with the specification
of what conforming programs and implementations are allowed to do.
This proposal does not attempt to do that since compiled functions are
not supported by this proposal in compiled constants.
The definition of similarity for random-states supports the
possibility of random states that are immutable because of being in
compiled constants.
Readtables need not be supported by an implementation. If a readtable
contains only symbols to represent functions, here is Cris Perdue's
suggested spec for similarity of readtables:
Character syntax type for each character in the table;
function for each readmacro character, mappings for
dispatch macros; whether terminating or nonterminating
for each readmacro.
Interest has been expressed by a number of people including users, in
support for user-definable "dumping" of CLOS objects and structure
instances. The cleanup issue LOAD-OBJECTS deals with this.
This subsumes the issue CONSTANT-ARRAY-ATTRIBUTES.
The main point of disagreement on this proposal over its handling
of constant functions.
Sandra Loosemore says:
I plan to submit an amendment to this proposal which would remove the
requirement that the compiler be able to dump non-compiled, non-closed
functions. The reason for removing this requirement is that there is
no way to portably construct an object which is guaranteed to be a
non-compiled, non-closed function. Note that implementations are
permitted to make all functions COMPILED-FUNCTIONs.
Dick Gabriel says:
I guess I pretty strongly object to leaving functions out of the list
of constants that can appear in compiled code. The part that's
disturbing is that such non-Lispy things like arrays, hashtables, and
pathnames get better treatment than functions, the most Lispy part of
Common Lisp. I wonder how many implementations will be forced to come
within an inch of the required functionality to implement a first-rate
CLOS?
The specification of the subset of functions that are acceptable as
compiled constants cannot be tested for within Common Lisp itself.
I suggest we ask implementors (Lucid included) to bite the bullet and
handle this case correctly. Won't our grandchildren appreciate us
treating Common Lisp like Lisp and not like PASCAL?
If we were to specify that all functions could appear as constants, we
would also need to clarify whether the closed-over variable bindings
become immutable, and also deal with whether bindings that are closed
over more than one function retain their uniqueness. Also, the cost
to implementors to add support for dumping non-interpreted functions
may be quite high.
∂13-Mar-89 0821 X3J13-mailer issue CONSTANT-CIRCULAR-COMPILATION, version 7
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 08:21:42 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA18436; Mon, 13 Mar 89 09:19:31 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02090; Mon, 13 Mar 89 09:19:28 -0700
Date: Mon, 13 Mar 89 09:19:28 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131619.AA02090@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue CONSTANT-CIRCULAR-COMPILATION, version 7
Forum: Compiler
Issue: CONSTANT-CIRCULAR-COMPILATION
References: Issue CONSTANT-COLLAPSING
Issue QUOTE-SEMANTICS
Category: CLARIFICATION, ADDITION
Edit History: V1, 07 Nov 1988, Sandra Loosemore
V2, 14 Nov 1988, Cris Perdue
V3, 12 Dec 1988, Sandra Loosemore (merge versions 1 and 2)
V4, 03 Jan 1989, Sandra Loosemore (add PRESERVE-SHARING-ONLY)
V5, 06 Jan 1989, Sandra Loosemore (minor wording changes)
V6, 08 Feb 1989, Sandra Loosemore (replace FLAG with YES)
V7, 11 Mar 1989, Sandra Loosemore (error terminology)
Status: Ready for release
Problem Description:
CLtL does not specify whether constants containing circular or
recursive references may be compiled. It is also not clear whether
the compiler must preserve sharing of EQ substructures; that is, whether
subobjects that are EQ in the source code must remain EQ after being
compiled.
The proposals below apply to constants appearing in a file compiled by
COMPILE-FILE. If proposal QUOTE-SEMANTICS:SAME-AS-COMPILE-FILE
passes, then the same constraints would apply to all constants. The
minimal scope over which sharing would be required to be detected is
over a single call to EVAL or COMPILE.
In the proposals that follow, "preserving EQness" means that
subobjects that are EQ in the source code must remain EQ after being
compiled; that is, things don't get "less EQ" after compilation.
(Note that coalescing of constants implies that things may get "more
EQ".)
Proposal CONSTANT-CIRCULAR-COMPILATION:NO
State that the consequences are undefined if an object containing a
circular reference appears as a constant to be compiled. State that
the compiler is not required to preserve EQness of substructures.
Rationale:
This proposal would not require any existing implementation to change.
Disallowing portable programs from containing circular constants
allows compiled file loaders to use somewhat simpler implementation
strategies (for example, to build constants in a strict bottom-up
fashion).
Proposal CONSTANT-CIRCULAR-COMPILATION:PRESERVE-SHARING-ONLY
State that the consequences are undefined if an object containing a
circular reference appears as a constant to be compiled. State that
the compiler is required to preserve EQness of substructures within a
file compiled with COMPILE-FILE.
Rationale:
Disallowing portable programs from containing circular constants
allows compiled file loaders to use somewhat simpler implementation
strategies (for example, to build constants in a strict bottom-up
fashion).
Some programs (such as PCL) have come to depend on COMPILE-FILE
preserving the EQness of uninterned symbols, and it is cleaner
to require sharing to be preserved in general instead of making
symbols be a special case. Requiring sharing to be preserved still
allows loaders to build constants bottom-up.
Proposal CONSTANT-CIRCULAR-COMPILATION:YES
State that objects containing circular references may legitimately
appear as constants to be compiled. State that the compiler is
required to preserve EQness of substructures within a file compiled
with COMPILE-FILE.
Rationale:
Users seem to expect this functionality, and some implementations
already provide it.
Current Practice:
A-Lisp preserves EQness of substructures (since it makes an effort to
collapse isomorphic structures) but signals an error if an attempt is
made to compile a circular constant. PSL and Utah Common Lisp both
get stuck in an infinite loop if an attempt is made to compile a
reentrant structure. The TI Explorer compiler is able to reproduce
recursive lists and arrays, but currently hangs in a loop on a
circular list. Neither the Explorer nor Symbolics Genera 7.x detects
EQness of list CDRs. Lucid handles circular constants correctly.
Franz uses a flag to control whether or not to attempt to detect
circular constants. KCL handles circular structures, but only detects
sharing of top-level structure (it does not traverse constants to look
for shared substructure).
Cost to implementors:
We know of no implementation that would have to change under proposal
NO.
For proposal YES, some implementations would require sweeping
changes; in some cases a completely different dumper/loader strategy
would have to be implemented.
The cost of proposal PRESERVE-SHARING-ONLY would fall somewhere in
between.
Cost to users:
The situation now is that programs which depend upon circularity or
sharing of substructure being preserved by the compiler are already
nonportable. Proposal NO simply formalizes the status quo. Proposal
YES would offer users functionality that is currently not portable.
Benefits:
An area of ambiguity in the language is removed.
Discussion:
The issue of compiler speed is largely a red herring on this issue;
the overhead of detecting circularities is generally quite small. The
main question is whether we should require some implementations to
completely redo their compiler/loader interface in order to support
circular constants.
It has been argued that any "serious" implementation will support
circular constants anyway, because of customer demand. However, since
there appears to be only one implementation (Lucid) that now
implements proposal YES in its full generality, perhaps the demand for
this feature is not really all that strong.
Earlier drafts of this writeup contained a proposal FLAG which would
have added a variable *COMPILE-CIRCLE*, similar to *PRINT-CIRCLE*.
However, there were unresolved problems about what would happen if the
value of this variable were altered within the file being compiled,
and it was generally agreed that this proposal didn't have any
particular advantages over proposal YES and just introduced
unnecessary hairiness.
Since it is usually fairly simple to detect circular constants,
Loosemore would support an amendment to proposals NO and
PRESERVE-SHARING-ONLY to change the first sentence to read:
State that the consequences are unspecified if an object containing
a circular reference appears as a constant to be compiled.
Implementations must either correctly handle the circular reference
or signal an error.
This is similar to the language which is already used in proposal
CONSTANT-COMPILABLE-TYPES:SPECIFY.
∂13-Mar-89 0824 X3J13-mailer issue CONSTANT-COLLAPSING, version 5
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 08:24:21 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA18594; Mon, 13 Mar 89 09:22:09 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02093; Mon, 13 Mar 89 09:22:05 -0700
Date: Mon, 13 Mar 89 09:22:05 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131622.AA02093@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue CONSTANT-COLLAPSING, version 5
Forum: Compiler
Issue: CONSTANT-COLLAPSING
References: CLtL p. 78, 87
Issue CONSTANT-MODIFICATION
Issue CONSTANT-COMPILABLE-TYPES
Issue EQUAL-STRUCTURE
Issue QUOTE-SEMANTICS
Category: CHANGE
Edit History: V1, 07 Nov 1988, Sandra Loosemore
V2, 12 Dec 1988, Sandra Loosemore
V3, 03 Jan 1989, Sandra Loosemore
V4, 06 Jan 1989, Sandra Loosemore
V5, 11 Mar 1989, Sandra Loosemore
Status: Ready for release
Problem Description:
CLtL states that an implementation is permitted to "collapse" or
coalesce constants appearing in code to be compiled if they are EQUAL.
The definition of EQUAL does not permit coalescing of more general
isomorphic data structures (such as arrays and structures), which is
often desirable.
Issue QUOTE-SEMANTICS deals with whether coalescing may be performed
only by COMPILE-FILE, or by COMPILE and EVAL as well. If proposal
QUOTE-SEMANTICS:SAME-AS-COMPILE-FILE passes, then coalescing could be
performed on all constants.
CLtL says: "An object is considered to be a constant in code to be
compiled if it is a self-evaluating form or contained in a QUOTE
form".
Proposal CONSTANT-COLLAPSING:GENERALIZE:
State the an implementation is permitted to coalesce constants
appearing in code to be compiled if they are equivalent under the
relationship defined in proposal CONSTANT-COMPILABLE-TYPES:SPECIFY.
Rationale:
There is little reason why implementations should not be allowed to
perform more general collapsing of structures, since the arguments
against doing so also apply to collapsing of EQUAL structures, which
is already permitted. The arguments for coalescing of EQUAL structures
(primarily space reduction) also apply to coalescing of structures that
are equivalent under a more general coalescing predicate.
Current Practice:
Both PSL/PCLS and A-Lisp collapse isomorphic arrays and structures,
and certain other data types that are defined internally as structures
(RANDOM-STATEs, for example). Lucid Common Lisp also uses a more
general coalescing predicate than EQUAL.
Cost to implementors:
None. This extends the range of permitted behavior for
implementations but does not require any implementation to change.
Cost to users:
Programs that depend on objects not being coalesced except when they
are EQUAL may break under this proposal. The only way one would be
able to detect that coalescing has taken place is if objects that were
not EQ in the source file become EQ after compilation; accessors on
the objects would return the same values regardless of whether or not
coalescing has taken place.
Benefits:
Collapsing of isomorphic arrays may lead to significant memory savings
in some applications.
Discussion:
This proposal depends heavily on issue CONSTANT-COMPILABLE-TYPES.
Some people believe that if the definition of EQUAL weren't "broken",
there wouldn't be any need for this proposal.
There is no inherent reason why the "coalescing predicate" must be the
same as the relationship used by the compiler/loader to construct
equivalent copies of objects of constants, but making the same rules
be applied in both situations simplifies the language somewhat.
∂13-Mar-89 0834 X3J13-mailer issue LOAD-TIME-EVAL, version 11
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 08:34:06 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA18990; Mon, 13 Mar 89 09:31:55 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02140; Mon, 13 Mar 89 09:31:50 -0700
Date: Mon, 13 Mar 89 09:31:50 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131631.AA02140@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue LOAD-TIME-EVAL, version 11
On this issue, we've come up with an improved version of the proposal that
was accepted at the January meeting.
Forum: Compiler
Issue: LOAD-TIME-EVAL
References: #, (p. 356), (EVAL-WHEN (LOAD) ...) (p. 69-70)
issue SHARP-COMMA-CONFUSION
Category: ADDITION
Edit history: 06-Jun-87, Version 1 by James Kempf
17-Jul-87, Version 2 by James Kempf
12-Nov-87, Version 3 by Pitman (alternate direction)
01-Feb-88, Version 4 by Moon
(from version 2 w/ edits suggested by Masinter)
06-Jun-88, Version 5 by Pitman
(fairly major overhaul, merging versions 3 and 4)
21-Sep-88, Version 6 by Moon (stripped down)
17-Oct-88, Version 7 by Loosemore (change direction again)
30-Dec-88, Version 8 by Loosemore (tweaks)
23-Jan-89, Version 9 by Loosemore (amendments)
02-Mar-89, Version 10 by Loosemore (new proposal)
11-Mar-89, Version 11 by Loosemore
Problem description:
Common Lisp provides reader syntax (#,) which allows the programmer
to designate that a particular expression within a program is to be
evaluated early (at load time) but to later be treated as a constant.
Unfortunately, no access to this capability is available to programs
which construct other programs without going through the reader.
Some computations can be deferred until load time by use of EVAL-WHEN,
but since EVAL-WHEN must occur only at toplevel, and since the nesting
behavior of EVAL-WHEN is quite unintuitive, EVAL-WHEN is not a general
solution to the problem of load-time computation of program constants.
Proposal R**2-NEW-SPECIAL-FORM was approved at the January 1989
meeting. After the meeting, some additional suggestions were made that
have been incorporated into proposal R**3-NEW-SPECIAL-FORM. The sections
of the two proposals that differ are marked with change bars in the margin.
Proposal (LOAD-TIME-EVAL:R**2-NEW-SPECIAL-FORM):
Add a new special form, LOAD-TIME-VALUE, which has the following
contract:
LOAD-TIME-VALUE form &optional read-only-p [Special Form]
LOAD-TIME-VALUE provides a mechanism for delaying evaluation of <form>
until the expression is in the "runtime" environment.
If a LOAD-TIME-VALUE expression is seen by COMPILE-FILE, the compiler
| performs normal semantic processing such as macro expansion but
| arranges for the evaluation of <form> to occur at load time in a null
lexical environment, with the result of this evaluation then being
treated as an immediate quantity at run time. It is guaranteed that
the evaluation of <form> will take place only once when the file is
loaded, but the order of evaluation with respect to the "evaluation"
of top-level forms in the file is unspecified.
If a LOAD-TIME-VALUE expression appears within a function compiled
with COMPILE, the <form> is evaluated at compile time in a null lexical
environment. The result of this compile-time evaluation is treated as
an immediate quantity in the compiled code.
In interpreted code, <form> is evaluated (by EVAL) in a null
lexical environment, and one value is returned. Implementations which
implicitly compile (or partially compile) expressions passed to
EVAL may evaluate the <form> only once, at the time this
compilation is performed. This is intentionally similar to the
freedom which implementations are given for the time of expanding
macros in interpreted code.
| Note that, in interpreted code, there is no guarantee as to when
| evaluation of <form> will take place, or the number of times the
| evaluation will be performed. Since successive evaluations of the
| same LOAD-TIME-VALUE expression may or may not result in an evaluation
| which returns a "fresh" object, destructive side-effects to the
| resulting object may or may not persist from one evaluation to the
| next. It is safest to explicitly initialize the object returned by
| LOAD-TIME-VALUE, if it is later modified destructively.
| Implementations must guarantee that each reference to a
| LOAD-TIME-VALUE expression results in at least one evaluation of its
| nested <form>. For example,
| (DEFMACRO CONS-SELF (X)
| `(CONS ,X ,X))
| (CONS-SELF (LOAD-TIME-VALUE (COMPUTE-IT)))
| must perform two calls to COMPUTE-IT; although there is only one
| unique LOAD-TIME-VALUE expression, there are two distinct references
| to it.
|
| In the case of a LOAD-TIME-VALUE form appearing in a quoted expression
| passed to EVAL, each call to EVAL must result in a new evaluation of
| <form>. For example,
| (DEFVAR X 0)
| (DEFUN FOO () (EVAL '(LOAD-TIME-VALUE (INCF X))))
| is guaranteed to increment X each time FOO is called, while
| (DEFUN FOO () (LOAD-TIME-VALUE (INCF X)))
| may cause X to be evaluated only once.
The READ-ONLY-P argument designates whether the result can be considered
read-only constant. If NIL (the default), the result must be considered
ordinary, modifiable data. If T, the result is a read-only quantity
which may, as appropriate, be copied into read-only space and/or shared
with other programs. (Because this is a special form, this argument is
-not- evaluated and only the literal symbols T and NIL are permitted.)
Rationale:
LOAD-TIME-VALUE is a special form rather than a function or macro
because it requires special handling by the compiler.
Requiring the compiler to perform semantic processing such as macro
expansion on the nested <form>, rather than delaying all such processing
until load time, has the advantages that fewer macro libraries may need
to be available at load time, and that loading may be faster and result
in less consing due to macroexpansion. If users really want to delay
macroexpansion to load time, this can be done with an explicit call to
EVAL, e.g.
(LOAD-TIME-VALUE (EVAL '(MY-MACRO)))
Allowing the same LOAD-TIME-VALUE to cause its nested <form> to be
evaluated more than once makes simplifies its implementation in
interpreters which do not perform a preprocessing code walk. It also
makes the rules for the time of its processing analogous to those
for macro expansion.
This proposal explicitly does -not- tie LOAD-TIME-VALUE to the #,
read macro. Doing so would be an incompatible change to the definition
of #, (which is reliably useful only -inside- quoted structure,
while LOAD-TIME-VALUE must appear -outside- quoted structure in a
for-evaluation position).
The requirement that LOAD-TIME-VALUE expressions be evaluated once per
reference (rather than once per unique expression) prevents problems
that could result by performing destructive side-effects on a value
that is unexpectedly referenced in more than one place.
Proposal (LOAD-TIME-EVAL:R**3-NEW-SPECIAL-FORM):
Add a new special form, LOAD-TIME-VALUE, which has the following
contract:
LOAD-TIME-VALUE form &optional read-only-p [Special Form]
LOAD-TIME-VALUE provides a mechanism for delaying evaluation of <form>
until the expression is in the "runtime" environment.
If a LOAD-TIME-VALUE expression is seen by COMPILE-FILE, the compiler
| performs its normal semantic processing (such as macro expansion and
| translation into machine code) on the form, but arranges for the
| execution of <form> to occur at load time in a null
lexical environment, with the result of this evaluation then being
treated as an immediate quantity at run time. It is guaranteed that
the evaluation of <form> will take place only once when the file is
loaded, but the order of evaluation with respect to the "evaluation"
of top-level forms in the file is unspecified.
If a LOAD-TIME-VALUE expression appears within a function compiled
with COMPILE, the <form> is evaluated at compile time in a null lexical
environment. The result of this compile-time evaluation is treated as
an immediate quantity in the compiled code.
In interpreted code, <form> is evaluated (by EVAL) in a null
lexical environment, and one value is returned. Implementations which
implicitly compile (or partially compile) expressions passed to
EVAL may evaluate the <form> only once, at the time this
compilation is performed. This is intentionally similar to the
freedom which implementations are given for the time of expanding
macros in interpreted code.
| If the same (compared with EQ) list (LOAD-TIME-VALUE <form>) is
| evaluated or compiled more than once, it is unspecified whether <form>
| is evaluated only once or is evaluated more than once. This can
| happen both when an expression being evaluated or compiled shares
| substructure, and when the same expression is passed to EVAL or to
| COMPILE multiple times. Since a LOAD-TIME-VALUE expression may be
| referenced in more than one place and may be evaluated multiple times
| by the interpreter, it is unspecified whether each execution returns
| a "fresh" object or returns the same object as some other execution.
| Users must use caution when destructively modifying the resulting
| object.
|
| If two lists (LOAD-TIME-VALUE <form>) are EQUAL but not EQ, their
| values always come from distinct evaluations of <form>. Coalescing
| of these forms is not permitted.
The READ-ONLY-P argument designates whether the result can be considered
read-only constant. If NIL (the default), the result must be considered
ordinary, modifiable data. If T, the result is a read-only quantity
which may, as appropriate, be copied into read-only space and/or shared
with other programs. (Because this is a special form, this argument is
-not- evaluated and only the literal symbols T and NIL are permitted.)
Rationale:
LOAD-TIME-VALUE is a special form rather than a function or macro
because it requires special handling by the compiler.
Requiring the compiler to perform semantic processing such as macro
expansion on the nested <form>, rather than delaying all such processing
until load time, has the advantages that fewer macro libraries may need
to be available at load time, and that loading may be faster and result
in less consing due to macroexpansion. If users really want to delay
macroexpansion to load time, this can be done with an explicit call to
EVAL, e.g.
(LOAD-TIME-VALUE (EVAL '(MY-MACRO)))
Allowing the same LOAD-TIME-VALUE to cause its nested <form> to be
evaluated more than once makes simplifies its implementation in
interpreters which do not perform a preprocessing code walk. It also
makes the rules for the time of its processing analogous to those
for macro expansion.
This proposal explicitly does -not- tie LOAD-TIME-VALUE to the #,
read macro. Doing so would be an incompatible change to the definition
of #, (which is reliably useful only -inside- quoted structure,
while LOAD-TIME-VALUE must appear -outside- quoted structure in a
for-evaluation position).
Allowing multiple references to the same LOAD-TIME-VALUE expression
to result in only one interpretation allows it to be specified more
cleanly. It also allows interpreters that do not perform a prepass
to cache LOAD-TIME-VALUE expressions.
Current Practice:
This is an addition to the language and has not yet been implemented.
Cost to Implementors:
In compiled code, (LOAD-TIME-VALUE <form>) is similar to
'#,<form>. Most implementations can probably make use of the same
mechanism they use to handle #, to handle LOAD-TIME-VALUE. Note that
#, does not currently provide a mechanism for dealing with
non-read-only-ness.
Implementing LOAD-TIME-VALUE in the interpreter should be fairly
straightforward, since one simply needs to evaluate the <form> in the
null lexical environment. Implementations that use a preprocessing
code walk in the interpreter to perform macro expansion could process
LOAD-TIME-VALUE forms at that time.
Some code-walkers would have to be taught about this new
special form. Such changes would likely be trivial.
Cost to Users:
Some code-walkers would have to be taught about this new
special form. Such changes would likely be trivial.
Benefits:
Users are given a mechanism that to force evaluation to be delayed
until load time that does not rely on a feature of the reader.
Discussion:
Earlier versions (up to version 7) of this proposal stated that
all semantic processing of the LOAD-TIME-VALUE form should be postponed
until load time.
The semantics of LOAD-TIME-VALUE would be simplified considerably if
the READ-ONLY-P argument were removed and destructive operations on
the result of evaluating <form> prohibited. However, some people feel
that the ability to destructively modify the value is an essential
feature to include.
"Collapsing" of multiple references to the same LOAD-TIME-VALUE
expression could be allowed for read-only situations, but it seems
like it would be more confusing to make it legal in some situations
and not in others.
A number of other alternatives have been considered on this issue,
including:
- A proposal for a new special form that would force evaluation of
the <form> to happen only once. This was rejected because of
implementation difficulties.
- A proposal to add a function making the "magic cookie" used by #,
available to user code. The current proposal does not prevent such
a function from being added, but this approach appeared to have
less support than making the hook available as a new special form.
- A proposal to remove #, entirely (issue SHARP-COMMA-CONFUSION).
- A suggestion to change the behavior of (EVAL-WHEN (LOAD) ...).
Kent Pitman says:
Although I'm willing to take multiple evaluation in the interpreter
as a compromise position, I would like it mentioned in the discussion
that this was only an expedient to getting this issue accepted at all,
and that I'm not really happy about it. I have said that I think a
number of our lingering problems (with EVAL-WHEN, COMPILER-LET, and
this -- for example) are due to the presence of interpreters which do
not do a semantic-prepass at a known time. If I had my way, we would
require a semantic pre-pass and we would then be able to forbid
multiple evaluations even in the interpreter.
Moon and Gray support proposal R**3-NEW-SPECIAL-FORM.
Pitman also expressed willingness to go along with
R**3-NEW-SPECIAL-FORM, but was somewhat concerned that coalescing
LOAD-TIME-VALUE results based on EQ-ness of the LOAD-TIME-VALUE form
could conceivably lead to trouble down the line. However, since he
could provide no actual examples to back up that worry, and since the
majority opinion was that some implementations would find a
restriction against such coalescing an undue burden, the decision was
made to just `note the concern' and proceed on. Sandra Loosemore and
JonL White concur with this position.
∂13-Mar-89 0837 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU Ullman and NAE
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89 08:37:44 PST
Received: from Tenaya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 13 Mar 89 08:29:11-PST
Received: by Tenaya.Stanford.EDU (NeXT-0.8/NeXT-0.8)
id AA05509; Mon, 13 Mar 89 08:26:40 PST
Date: Mon, 13 Mar 89 08:26:40 PST
From: nilsson@tenaya.Stanford.EDU (Nils Nilsson)
Message-Id: <8903131626.AA05509@Tenaya.Stanford.EDU>
To: faculty@score.Stanford.EDU
Subject: Ullman and NAE
Cc: nilsson@Tenaya.Stanford.EDU
(If you already received a message like this, please
forgive this extra one. I'm having trouble with a new
mailing system.)
I have just learned that our very own Jeff Ullman
has been elected to the National Academy of
Engineering! This is great news for Jeff and for
CS at Stanford. Congratulations to Jeff on behalf
of all of us!
Carolyn Tajnai: I assume that you will get this
news to the Campus Report with any additional
background that may be needed (picture, etc.) Jeff
is reading electronic mail while on sabbatical, so
maybe he could provide an extra detail or two if
needed.
-Nils
∂13-Mar-89 0840 X3J13-mailer Issue: UNSOLICITED-MESSAGES
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89 08:40:09 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Mon, 13 Mar 89 11:34:05 EST
Date: Mon, 13 Mar 89 11:35 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: UNSOLICITED-MESSAGES
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Cc: chapman%aitg.DEC@decwrl.dec.com, x3j13@sail.stanford.edu
In-Reply-To: <890312191349.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-Id: <19890313163525.7.BARMAR@OCCAM.THINK.COM>
Date: Sun, 12 Mar 89 19:13 EST
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
I agree that this is an important issue.
I am not sure I agree with the proposed solution -- partly because
I don't think it goes nearly far enough, and partly because I think the
wording for the place where it stops encourages might actually encourage
more `abuse' than currently exists.
I think it should be possible to know with certainly that calling EQ,
CONS, or even COMPILE, was not going to do I/O, at least in
the normal case.
Do progress notes in the wholine count as output? If not, why not? If
so, are you proposing that they be prohibited? In Genera, calling
COMPILE displays "Compiling <name>" in the wholine, and calling
READ-CHAR on a console stream displays "User Input" in the wholine. I
like these things, but I think it will be difficult to express this
distinction in general enough terms in the standard.
In exceptional cases, CONS might produce GC warnings
or COMPILE might produce compiler warnings, but never should COMPILE
type out anything like
Compiling FOO.
or should EQ type out
Performing EQ comparison of #<FOO 32> and #<BAR 17>.
Right now, nothing assures me of this and I find that disturbing.
Why is this problem unique to Lisp? Is there any wording in the C
standard that explicitly prohibits malloc() from causing output? I
doubt it, yet I don't think they find this disturbing.
I think market forces should be enough to prevent really silly
unsolicited messages, just as all serious Lisp implementations have a GC
even though CLtL never mentions it.
barmar
∂13-Mar-89 0853 X3J13-mailer issue MACRO-CACHING, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 08:49:54 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA19529; Mon, 13 Mar 89 09:47:42 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02151; Mon, 13 Mar 89 09:47:38 -0700
Date: Mon, 13 Mar 89 09:47:38 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131647.AA02151@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue MACRO-CACHING, version 2
Issue: MACRO-CACHING
Forum: Compiler
References: 8.2 Macro Expansion (CLtL pp151-152),
Issues PACKAGE-CLUTTER, LISP-SYMBOL-REDEFINITION,
QUOTE-SEMANTICS (a.k.a. QUOTE-MAY-COPY),
and MACRO-ENVIRONMENT-EXTENT
Category: Clarification
Edit history: 31-Jan-89, Version 1 by Pitman
11-Mar-89, Version 2 by Loosemore (add discussion)
Status: Ready for release
Background:
CLtL suggests that macro caching is a legitimate strategy.
Two particular kinds of caching are common:
Displacement. A macro expansion function displaces the actual macro in
order to avoid any later need for lookup.
Table. A macro expression is looked up in a cache (such as a hash table)
to avoid having to run the expander code.
While CLtL seems to expressly suggest these strategies to be legitimate,
linguistic constraints show that in most cases they are not. The problems
are things like:
- lexical scoping (MACROLET and SYMBOL-MACROLET, and FLET and LET to
the extent that they shadow the effect of MACROLET and SYMBOL-MACROLET,
respectively).
- ``read only'' structure
To see the problem, consider the following examples:
(SETQ FOO1 '(FOO))
(EVAL `(LIST (MACROLET ((FOO (&WHOLE FORM) '(+ 1 1))) ,FOO1)
(MACROLET ((FOO (&WHOLE FORM) '(+ 1 2))) ,FOO1)))
=> (2 3)
Note that because the lexical contour may vary for an EQL expression,
however, displacing the expansion will cause confusion:
(DEFUN DISPLACE (X Y)
(SETF (CAR X) (CAR Y))
(SETF (CDR X) (CDR Y))
X)
(DEFVAR FOO2 '(FOO))
(EVAL `(LIST (MACROLET ((FOO (&WHOLE FORM)
(DISPLACE FORM '(+ 1 1)))) ,FOO2)
(MACROLET ((FOO (&WHOLE FORM)
(DISPLACE FORM '(+ 1 2)))) ,FOO2)))
=> (2 2)
CLtL suggests that a displacement hook might be placed in
*MACROEXPANSION-HOOK*. The above example shows that to be an
unreliable technique.
If this were not enough, displacement is also inappropriate because
no Common Lisp primitive can tell the difference between regular list
structure and read-only list structure. Since a macro form being
expanded might have been read-only in some implementations (e.g., EVAL
of a quoted list), the macro cannot reliably side-effect the structure.
In the case of table-lookup, the problem is more complicated.
Table-lookup does not have a necessary effect beyond the particular
lookup being done at the moment. To do table-lookup correctly relies
on the key being not only the expression but also the lexical
environment object. Whether the cost of making and throwing away so
many tables was worth the savings over running the macro expander is
not at all clear. And the GC effects of caching every macro environment
ever seen may be extraordinary, however correctness could in principle
be preserved by doing such a two-dimensional lookup... at least unless
we decide that macro environments have only dynamic extent. [A separate
proposal, MACRO-ENVIRONMENT-EXTENT, addresses this issue. If it passed,
then there would really be no way for users to do reliable macro caching
without cooperation from the system to have the cache be part of the
environment itself.]
Problem Description:
Macro caching by displacement is provably not semantically valid.
Macro caching by table lookup is difficult for a user to do correctly,
and in any case is not possible to handle efficiently in user code.
Proposal (MACRO-CACHING:DISALLOW):
1. a. Clarify that macro caching by displacement is not semantically
valid in user code.
b. Clarify that macro caching by displacement is semantically valid
for system macros and special forms, provided that such caching
does not prejudice the expansion of user-code contained in any
displaced code. For example:
(PROG () (FOO))
could displace to a BLOCK, but the (FOO) must appear un-expanded
in the BLOCK in case the BLOCK occurs in more than one lexical
environment.
2. a. Clarify that macro caching by table lookup is not semantically
valid in user code in order to correctly respect the lexical
environment.
Implementations are free to extend the language to permit such
lookup and to offer functions which support it in a more efficient
way, but code using such functions would, of course, not be portable.
b. Clarify that macro caching by table lookup is valid for the system,
but only if it correctly respects the lexical environment.
Proposal (MACRO-CACHING:RESTRICT):
Like DISALLOW, but change 2a to:
Clarify that macro caching by table lookup is semantically valid only
if the lookup is keyed both on the form and the environment.
Implementations are free to extend the language to offer functions
which support it in a more efficient way, but code using such functions
would, of course, not be portable.
Rationale:
1. a. Displacement has effects which by their nature transcend
lexical boundaries.
b. The system can assure that lexical boundaries are irrelevant in some
cases because users are not permitted to redefine or shadow definitions
in the initial LISP system. [See issues PACKAGE-CLUTTER and
LISP-SYMBOL-REDEFINITION.]
2. a. Users can only associate an environment with a macro cache table
in a very clumsy way. Also, Permitting them to do so at all forces
macro environments to have indefinite extent, and works against
efficiency in compilers.
b. The system is capable of allocating space in an environment object
for a macro cache which can be reliably kept up in synch with the
lexical environment environment.
Test Case:
;; #1: File compiling this definition in some implementations will produce
;; a definition that returns read-only list structure. The call to EVAL
;; on the result must not try to modify the read-only structure during
;; macroexpansion. [See issue QUOTE-SEMANTICS.]
(DEFUN READ-ONLY-FOO () '(MACROLET ((FOO (&WHOLE FORM) (+ 1 1))) (FOO)))
(EVAL (READ-ONLY-FOO))
=> 2
;; #2: This constructs a form and then uses it in two places in another
;; constructed form. Each of the uses is in a different lexical
;; contour, so must be expanded differently.
(LET ((FOO (LIST 'FOO)))
(EVAL `(LIST (MACROLET ((FOO (&WHOLE FORM) '(+ 1 1))) ,FOO)
(MACROLET ((FOO (&WHOLE FORM) '(+ 1 2))) ,FOO))))
=> (2 3)
;; #3: This is effectively the same thing but involves a MACROLET
;; shadowing a DEFMACRO rather than two MACROLETs, since some
;; implementations might only be caching expansions that come
;; from DEFMACRO.
(DEFMACRO FOO (&WHOLE FORM) '(+ 1 1))
(LET ((FOO (LIST 'FOO)))
(EVAL `(LIST ,FOO (MACROLET ((FOO (&WHOLE FORM) '(+ 1 2))) ,FOO))))
=> (2 3)
Current Practice:
Symbolics Genera does not use displacing or table caching in either
the interpreter or compiler.
Symbolics Cloe, a compiled only implementation, uses table caching
to boost compilation by a little. Running the test cases above turned
up a bug (in test case #3), which is now in the process of being fixed.
[The fact that a bug was turned up in code written by a CL implementor
is an existence proof that the potential for trouble was not imagined.]
Both Symbolics Cloe and Symbolics Genera support *MACROEXPANSION-HOOK*,
leaving open the possibility of users bringing disasters upon themselves.
Macro environment objects in Symbolics Genera are stack-allocated, so
have only dynamic extent.
Cost to Implementors:
This proposal is upward compatible with correct implementations.
Cost to Users:
There is no cost to users of the RESTRICT proposal, unless they were doing
semantically invalid caching.
The cost to users of the DISALLOW proposal is a loss of speed in some cases
which are semantically valid. In general, however, the efficiency and
usefulness of such caching is subject to question in code intended to be
ported. Given that implementations are not required to ever give the same
environment object twice, the caching may be all for naught in some
implementations.
Cost of Non-Adoption:
Continued widespread confusion about whether displacement is a legitimate
implementation technique for user code.
Benefits:
Since *MACROEXPANSION-HOOK* is in the Lisp package, multiple applications
in the same environment share its effects. Often one application will
clobber another's hook, or introduce a hook that is not desirable to other
applications when none previously existed. Since a common use of
*MACROEXPANSION-HOOK* is to install a macro caching mechanism, clarifying
the situations in which *MACROEXPANSION-HOOK* should not be used will
decrease the likelihood of one program breaking, slowing down, or otherwise
adversely affecting another.
Aesthetics:
Most people agree that macro caching techniques are only supposed to improve
speed without affecting semantics. This proposal is only intended to
underscore that necessary truth. Insofar as this is only a clarification,
it presumably has no significant aesthetic impact.
Discussion:
Pitman thinks it's a good idea to clarify this issue because it's not really
spelled out now and it's the sort of thing programmers can waste a lot of
time bickering about to no good end. Either the functionality is reliable
and should be encouraged, or it is not reliable and should be discouraged
or forbidden. Pitman supports the DISALLOW proposal because it leaves open
the possibility of making macro environments have dynamic extent, but he
can live with the RESTRICT position, which he believes represents the
status quo.
Bob Laddaga (a Cloe maintainer who reviewed a draft of this proposal)
supports the DISALLOW option as well.
David Grays says:
I can accept MACRO-CACHING:DISALLOW.
The Explorer evaluator does displacement of macros, but is careful to
correctly handle the cases exemplified in your test cases #1 and #2.
It does not do the right thing for #3, but that is a bug that can fairly
easily be fixed.
Sandra Loosemore says:
This issue is closely tied to MACRO-ENVIRONMENT-EXTENT. If we decide
environments have (or can be made to have) indefinite extent, I see no
reason not to go with MACRO-CACHING:RESTRICT. On the other hand, if
we decide environments have only dynamic extent, proposal
MACRO-CACHING:DISALLOW is the only one that makes sense.
∂13-Mar-89 0855 X3J13-mailer Issue: UNSOLICITED-MESSAGES
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Mar 89 08:54:56 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 555652; Mon 13-Mar-89 11:51:33 EST
Date: Mon, 13 Mar 89 11:51 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: UNSOLICITED-MESSAGES
To: barmar@Think.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, chapman%aitg.DEC@decwrl.dec.com,
x3j13@sail.stanford.edu
In-Reply-To: <19890313163525.7.BARMAR@OCCAM.THINK.COM>
Message-ID: <890313115113.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Mon, 13 Mar 89 11:35 EST
From: Barry Margolin <barmar@Think.COM>
Date: Sun, 12 Mar 89 19:13 EST
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
I agree that this is an important issue.
I am not sure I agree with the proposed solution -- partly because
I don't think it goes nearly far enough, and partly because I think the
wording for the place where it stops encourages might actually encourage
more `abuse' than currently exists.
I think it should be possible to know with certainly that calling EQ,
CONS, or even COMPILE, was not going to do I/O, at least in
the normal case.
Do progress notes in the wholine count as output? If not, why not? ...
No. They are passive. The function in question does not output to the
wholine. Rather, it arranges information such that a foreign process
can access it and display it. For example, if 500 calls to LOAD are done
in three second, you don't always get 500 progress messages. That is
because the output is done by the foreign process doing the polling and
not the process which is running the CL code. I think this distinction
is important. Indeed, if the running process could block, signal an
error, etc. due to problems in I/O then it would not be a good idea.
If so, are you proposing that they be prohibited?
No.
In Genera, calling
COMPILE displays "Compiling <name>" in the wholine, and calling
READ-CHAR on a console stream displays "User Input" in the wholine.
No. COMPILE does no display. A foreign process which is working by polling
does. This is no different than a foreign process doing any kind of
debugging activity.
I like these things, but I think it will be difficult to express this
distinction in general enough terms in the standard.
I don't think it's that difficult.
In exceptional cases, CONS might produce GC warnings
or COMPILE might produce compiler warnings, but never should COMPILE
type out anything like
Compiling FOO.
or should EQ type out
Performing EQ comparison of #<FOO 32> and #<BAR 17>.
Right now, nothing assures me of this and I find that disturbing.
Why is this problem unique to Lisp? Is there any wording in the C
standard that explicitly prohibits malloc() from causing output? I
doubt it, yet I don't think they find this disturbing.
Maybe it's because C people have traditionally been willing to settle
for less. :-) Seriously, I think it's a clear hole in their standard.
People would probably flame if things that weren't documented as doing
I/O were to suddenly start doing it.
I think market forces should be enough to prevent really silly
unsolicited messages,
Really I don't. COMPILE is a notable offender. Real implementations have
been known to print "Compiling FOO." on *TERMINAL-IO* and this proposal
does not forbid it.
In some cases, market pressure can --- after some number of months --
get things back in line. In others, implementors just point to the standard
and either say "it doesn't say anything" or even worse suggest that the
reason it doesn't say it is because it wants to leave room.
Not all implementors come from our culture. Often, those that don't
would -prefer- to have little `hints' (rules?) like this specified so
that the process of making incidental decisions would be easier. For
example, it's not unreasonable that implementors find themselves asking
"Should COMPILE say something?" -- It's been traditional for compilers
in languages where you couldn't invoke the compiler at runtime to do
typeout, so they might naturally assume that the same should be true
here. Certainly it's natural for them to at least answer the question.
just as all serious Lisp implementations have a GC
even though CLtL never mentions it.
This comes up because it's a "hard issue" and new implementors naturally
tend to discuss "hard issues" with other implementors before even getting
started. My guess is that no new implementor would consider calling up
Moon or JonL or Masinter to ask what the I/O behavior of COMPILE should
be. Probably they would just make a guess, hope it was right, and move on
to the next seemingly trivial decision.
∂13-Mar-89 0853 X3J13-mailer issue COMPILER-VERBOSITY, version 6
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89 08:53:16 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Mon, 13 Mar 89 11:48:42 EST
Date: Mon, 13 Mar 89 11:50 EST
From: Barry Margolin <barmar@Think.COM>
Subject: issue COMPILER-VERBOSITY, version 6
To: cl-compiler@sail.stanford.edu
Cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131546.AA02078@defun.utah.edu>
Message-Id: <19890313165001.9.BARMAR@OCCAM.THINK.COM>
I see the benefit of :PRINT, but do we really need :VERBOSE? What's the
difference between
(compile path :verbose t)
and
(format t "~&Compiling file ~A...~%" path)
(compile-file path)
(format t "~&done.~%")
If any users want to have this controlled by a global variable, they can
do what we (Thinking Machines) did years ago and package it up in their
own function. At this stage of the game I don't see the need to add
gratuitous features like this.
:PRINT is less gratuitous because it implements a feature that the user
can't add himself.
barmar
∂13-Mar-89 0924 X3J13-mailer issue QUOTE-SEMANTICS, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 09:23:57 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA20995; Mon, 13 Mar 89 10:21:38 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02184; Mon, 13 Mar 89 10:21:33 -0700
Date: Mon, 13 Mar 89 10:21:33 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131721.AA02184@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue QUOTE-SEMANTICS, version 2
This issue replaces QUOTE-MAY-COPY, which was distributed and discussed
briefly at the last meeting.
Forum: Compiler
Issue: QUOTE-SEMANTICS
Subsumes: Issue QUOTE-MAY-COPY
References: CLtL p. 55, 78, 86, 143
Issue CONSTANT-COLLAPSING
Issue CONSTANT-COMPILABLE-TYPES
Issue CONSTANT-CIRCULAR-COMPILATION
Category: CLARIFICATION
Edit History: V1, 22 Jan 1989, Sandra Loosemore
V2, 13 Mar 1989, Sandra Loosemore (discussion)
Status: Ready for release
Problem Description:
Is it permissible for COMPILE and EVAL to coalesce or copy constants?
Are there constraints upon what kinds of objects may appear as
constants in code processed by COMPILE or EVAL, similar to those for
COMPILE-FILE?
CLtL p86 states that (QUOTE <x>) simply returns <x>. On p55 it is
mentioned that the only self-evaluating forms that may be copied are
numbers or characters. It is also stated that an implementation is
permitted to collapse (or coalesce) EQUAL constants "appearing in code
to be compiled" (p78), which is defined to mean self-evaluating forms
or objects contained in a QUOTE form (without reference to whether the
form is processed by EVAL, COMPILE, or COMPILE-FILE).
Because of its nature as a file processor, COMPILE-FILE generally must
cause copies of constants to be constructed when the compiled code is
loaded. In a number of existing Lisp implementations, COMPILE also
causes constant objects to be copied and/or coalesced. There is also
at least one implementation where constants are copied by EVAL in some
circumstances.
Proposal QUOTE-SEMANTICS:NO-COPYING:
State that copying or coalescing of constants appearing in code
processed by EVAL and COMPILE is not permitted; the resulting program
must reference objects that are EQL to the corresponding objects in
the source code. The constraints on what kinds of objects may appear
as constants (described in issues CONSTANT-COMPILABLE-TYPES and
CONSTANT-CIRCULAR-COMPILATION) apply only to COMPILE-FILE.
Rationale:
This proposal is consistent with what many people think of as the
"traditional" semantics for QUOTE. It gives users maximum flexibility
about what kinds of objects may appear as constants.
Proposal QUOTE-SEMANTICS:COPYING-ALLOWED-BUT-NO-CONSTRAINTS:
State that copying or coalescing of constants appearing in code
processed by EVAL and COMPILE is permitted. Copying or coalescing may
only take place when the source code is "promoted" to being a program
by EVAL or COMPILE, not at runtime. Function definitions are promoted
to being a program when the form enclosing the definition (e.g., a
FUNCTION or DEFUN form) is promoted.
Any object may validly appear as a constant in code processed by EVAL
or COMPILE. The constraints on what kinds of objects may appear as
constants (described in issues CONSTANT-COMPILABLE-TYPES and
CONSTANT-CIRCULAR-COMPILATION) apply only to COMPILE-FILE.
Rationale:
This proposal is the most consistent with the semantics stated in CLtL.
It gives users maximum flexibility about what kinds of objects may
appear as constants.
Proposal QUOTE-SEMANTICS:SAME-AS-COMPILE-FILE:
State that copying or coalescing of constants appearing in code
processed by EVAL and COMPILE is permitted. Copying or coalescing may
only take place when the source code is "promoted" to being a program
by EVAL or COMPILE, not at runtime. Function definitions are promoted
to being a program when the form enclosing the definition (e.g., a
FUNCTION or DEFUN form) is promoted.
The constraints on what kinds of objects may appear as constants
(described in issues CONSTANT-COMPILABLE-TYPES and
CONSTANT-CIRCULAR-COMPILATION) apply to EVAL and COMPILE as well as to
COMPILE-FILE.
Rationale:
This makes the rules for handling of constants consistent between
EVAL, COMPILE, and COMPILE-FILE. It gives implementors maximum
flexibility in handling constants in EVAL and COMPILE.
Current Practice:
Implementations in which COMPILE attempts to copy all constants
include PSL/PCLS and Kyoto Common Lisp.
In Lucid Common Lisp, constants are not normally copied by COMPILE,
but since COMPILE does coalesce constants, it may cause QUOTE to
return an object which is not EQL to the object which appeared in the
source code.
Symbolics Genera has COMPILE copy list, string, non-displaced array,
and (I-Machine only) closure constants, but Moon says he thinks this
is wrong.
There is known to be at least one implementation where expanding the
DEFUN macro causes all constants in the body of the function to be
copied.
Cost to implementors:
Proposal NO-COPYING would involve a significant cost in those
implementations where constants are now copied or coalesced by EVAL
and COMPILE. Some implementations would also require substantial
changes to support proposal COPYING-ALLOWED-BUT-NO-CONSTRAINTS. The
aspect that is likely to cause the most problems is that, in some
implementations, the garbage collector assumes that constants
referenced in compiled code have been copied to read-only storage and
do not need to be scanned or relocated.
Proposal SAME-AS-COMPILE-FILE has no adoption cost above what is
required to support issues CONSTANT-COMPILABLE-TYPES and
CONSTANT-CIRCULAR-COMPILATION.
Cost to users:
Proposals COPYING-ALLOWED-BUT-NO-CONSTRAINTS and SAME-AS-COMPILE-FILE
may break some existing programs that assume constants in code
processed by EVAL or COMPILE are always EQL to the corresponding
objects in the source code. Proposal SAME-AS-COMPILE-FILE may also
break existing programs that depend on referencing "undumpable"
constants in code processed by EVAL or COMPILE. In both cases,
however, the behavior is already nonportable. Both proposals would
permit implementations in which these programs now work to continue to
provide their existing behavior.
Benefits:
The semantics of QUOTE are clarified.
Discussion:
This issue subsumes issue QUOTE-MAY-COPY, which caused a very lengthy
debate on the cl-compiler mailing list.
This issue relates to conformance requirements. Accepting either of
proposals NO-COPYING or COPYING-ALLOWED-BUT-NO-CONSTRAINTS would mean
that not all conforming programs could be compiled with COMPILE-FILE.
Some people may find this disturbing, particularly since one of the
goals of Common Lisp has been to try to eliminate differences in
semantics between compiled and interpreted code.
Loosemore supports proposal QUOTE-SEMANTICS:SAME-AS-COMPILE-FILE,
since it requires essentially no conversion cost for implementors and
does not break any user programs that are not already nonportable.
JonL White says:
Since we have already passed the proposal that permits constants to
be "read-only" -- it is an error to modify them -- and have already
passed the proposal that allows access to updateable structures --
LOAD-TIME-EVAL -- then there is no excuse for being overly concerned
with the storage address of quoted data. People who have mistakenly
used structured constants as updatable data should convert over to
either LOAD-TIME-EVAL or DEFPARAMETER.
Kent Pitman says:
The problem is that a lot of copying advocates have been going around
trying to use "the need for copying" as leverage for restricting
the set of things which I may quote. My view is that it is my write [sic]
to quote whatever I want, and it's up to the person who thinks they
can do something fun with copying to not get themselves in deeper than
they can handle.
Jeff Dalton says:
I would agree [with Pitman's remarks] too. My only quibble is that
it's not just "the need for copying" that's used a lever.
"Consistency with file compilation" is also being used as a lever.
∂13-Mar-89 0929 X3J13-mailer issue SAFE-CODE, version 1
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 09:29:10 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA21179; Mon, 13 Mar 89 10:26:59 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02193; Mon, 13 Mar 89 10:26:56 -0700
Date: Mon, 13 Mar 89 10:26:56 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131726.AA02193@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue SAFE-CODE, version 1
Issue: SAFE-CODE
Forum: Compiler
References: OPTIMIZE declaration (p160),
Issue ERROR-TERMINOLOGY
Category: CLARIFICATION/CHANGE
Edit history: 07-Mar-89, Version 1 by Pitman
Status: Ready for release
Problem Description:
The new error terminology refers to ``safe code'' in the definition
of the term and CLtL refers to
individual meanings of OPTIMIZE qualities, but there is no standardized
way of relating the two concepts.
Proposal (SAFE-CODE:SAFETY-3):
Define that, formally, the term ``safe code'' is code refers to any
code in which the OPTIMIZE quality for SAFETY has a value of 3.
Implementors might wish to consider treating other situations as safe
as well, but in making that decision both the relative values of other
OPTIMIZE qualities and the idiosyncratic properties of the particular
implementation should also be taken into account.
Examples:
1. The body of the following is safe...
a. (LOCALLY (DECLARE (OPTIMIZE (SAFETY 3))) . body)
b. (LOCALLY (DECLARE (OPTIMIZE SAFETY )) . body)
2. The body in each of the following is unsafe. They might
or might not be treated as safe, possibly depending
on the values of other qualities and specifics of the
implementation.
a. (LOCALLY (DECLARE (OPTIMIZE (SAFETY 0))) . body)
b. (LOCALLY (DECLARE (OPTIMIZE (SAFETY 1))) . body)
c. (LOCALLY (DECLARE (OPTIMIZE (SAFETY 2))) . body)
Rationale:
Programmers will probably intuitively expect that the term
``highest safety'' refers to giving the SAFETY quality its
highest safety.
Current Practice:
Implementors ...
Symbolics Genera does error checking always, and ignores OPTIMIZE
declarations.
Symbolics Cloe heeds OPTIMIZE declarations, but effectively makes
`judgment calls' in every case because there is no clear guidance
on how to interpret them.
Programmers ...
Many programmers write (DECLARE (SPEED 0) (SAFETY 3)) even when all
they really want to control is SAFETY because they are afraid that
unless they explicitly sacrifice speed, the compiler will ignore
their plea for error checking.
Cost to Implementors:
Some implementations might require a lot of nitpicky little changes.
Cost to Users:
Technically none. No portable code can really rely on much of any
reliable effect out of any of the OPTIMIZE qualities. However, some
users may rely on implementation-specific features of implementations,
and if those implementations are forced to change, non-portable user
code might break in some ways.
Cost of Non-Adoption:
The meaning of ``safe code'' will not be clearly defined.
Benefits:
Programmers will be able to say what they mean. They can stop
superstitiously putting (SPEED 0) next to (SAFETY 3) just to
assure they get safe code.
Aesthetics:
Improved. This will make the English align well with the code.
Discussion:
It is very important that we reach consensus in some form on this issue.
Pitman supports SAFE-CODE:SAFETY-3.
∂13-Mar-89 0945 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU faculty lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89 09:45:09 PST
Received: from Tenaya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 13 Mar 89 09:40:24-PST
Received: by Tenaya.Stanford.EDU (NeXT-0.8/NeXT-0.8)
id AA05533; Mon, 13 Mar 89 08:36:47 PST
Date: Mon, 13 Mar 89 08:36:47 PST
From: nilsson@Tenaya.Stanford.EDU (Nils Nilsson)
Message-Id: <8903131636.AA05533@Tenaya.Stanford.EDU>
To: faculty@score.Stanford.EDU
Subject: faculty lunch
Cc: nilsson@Tenaya.Stanford.EDU
Tomorrow's faculty lunch will feature as guests
Bruce Hinchliffe from the Development Office and
Dwain Fullerton from the Dean's Office. Our topic
will be fundraising for the new CS building. We in
CS are about to be "turned loose" to help raise money
for the new building. Bruce and Dwain will discuss the
process and how we can help put the bite on some of
our affluent friends. 12:15 in mjh 146.
Also please don't forget the other important Tuesday
events:
1) faculty meeting to discuss new theory candidates
at 2:30 in mjh 146, and
2) Mike Dertouzos's lecture at the CS Colloquium
at 4:15 in the downstairs Jordan lecture hall.
-Nils
∂13-Mar-89 1007 @Score.Stanford.EDU:eaf@sumex-aim.stanford.edu Re: faculty lunch
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89 10:07:35 PST
Received: from sumex-aim.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 13 Mar 89 10:04:05-PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA13376; Mon, 13 Mar 89 10:05:05 PST
Date: Mon, 13 Mar 1989 10:05:03 PST
From: Edward A. Feigenbaum <eaf@sumex-aim.stanford.edu>
To: nilsson@tenaya.stanford.edu (Nils Nilsson)
Cc: faculty@score.stanford.edu, nilsson@tenaya.stanford.edu,
csd@score.stanford.edu
Subject: Re: faculty lunch
In-Reply-To: Your message of Mon, 13 Mar 89 08:36:47 PST
Message-Id: <CMM.0.88.605815503.eaf@sumex-aim.stanford.edu>
Re Nils' reminder of Mike Dertouzos' lecture tomorrow:
Mike is an excellent speaker, and the study he will be reporting on is
fascinating. It's the MIT study of American productivity in recent years.
Mike has been chairman of that study. They have some important things to say
about the effect (or non-effect) of computers on American productivity.
This is a VERY worthwhile colloquium to attend.
Ed Feigenbaum
∂13-Mar-89 1014 X3J13-mailer Issue: UNSOLICITED-MESSAGES
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89 10:14:33 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Mon, 13 Mar 89 13:09:40 EST
Date: Mon, 13 Mar 89 13:10 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: UNSOLICITED-MESSAGES
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Cc: chapman%aitg.DEC@decwrl.dec.com, x3j13@sail.stanford.edu
In-Reply-To: <890313115113.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-Id: <19890313181059.0.BARMAR@OCCAM.THINK.COM>
Date: Mon, 13 Mar 89 11:51 EST
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Date: Mon, 13 Mar 89 11:35 EST
From: Barry Margolin <barmar@Think.COM>
Do progress notes in the wholine count as output? If not, why not? ...
No. They are passive. The function in question does not output to the
wholine. Rather, it arranges information such that a foreign process
can access it and display it. For example, if 500 calls to LOAD are done
in three second, you don't always get 500 progress messages. That is
because the output is done by the foreign process doing the polling and
not the process which is running the CL code. I think this distinction
is important. Indeed, if the running process could block, signal an
error, etc. due to problems in I/O then it would not be a good idea.
So, the acceptability of progress notes has nothing to do with the
stream they are displayed on, only the fact that they are displayed by a
background process? This implies that a single-tasking machine that
displayed progress notes synchronously would therefore be unacceptable.
I find this distinction extremely arbitrary, since it is based only on
the implementation, not the program-visible effects.
I like these things, but I think it will be difficult to express this
distinction in general enough terms in the standard.
I don't think it's that difficult.
We'll have to come up with a general definition of passive output versus
active output. And we'll still have to make sure that passive output
isn't allowed to go to *STANDARD-OUPTUT*.
Why is this problem unique to Lisp? Is there any wording in the C
standard that explicitly prohibits malloc() from causing output? I
doubt it, yet I don't think they find this disturbing.
Maybe it's because C people have traditionally been willing to settle
for less. :-) Seriously, I think it's a clear hole in their standard.
People would probably flame if things that weren't documented as doing
I/O were to suddenly start doing it.
Actually, I think the difference is that Common Lisp includes some
operations that are not traditionally included in runtime libraries,
COMPILE, COMPILE-FILE, and LOAD being the most notable ones. No
Lisp implementor would even think of having CONS or EQ produce output,
just as the C standard doesn't need to say that malloc() is silent.
Perhaps this means that since we have such unusual runtime facilities,
we can't rely on common sense as other languages do. I would be willing
to support a blanket statement that said that no output may be produced
by functions other than that specified in the standard or due to the
signalling of conditions detected by the function.
Would this prevent an implementation from having a *DEBUG-CONS* variable
that turns on debugging output by CONS?
barmar
∂13-Mar-89 1046 X3J13-mailer Issue: UNSOLICITED-MESSAGES
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Mar 89 10:46:36 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 555842; Mon 13-Mar-89 13:43:40 EST
Date: Mon, 13 Mar 89 13:43 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: UNSOLICITED-MESSAGES
To: x3j13@sail.stanford.edu
cc: barmar@Think.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM,
chapman%aitg.DEC@decwrl.dec.com
In-Reply-To: <890313115113.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <890313134321.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
[Further discussion on this topic will take place on CL-Editorial.]
∂13-Mar-89 1450 X3J13-mailer **DRAFT** issue CLOS-MACRO-COMPILATION, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 14:50:22 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA07805; Mon, 13 Mar 89 15:48:10 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02496; Mon, 13 Mar 89 15:48:08 -0700
Date: Mon, 13 Mar 89 15:48:08 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903132248.AA02496@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: **DRAFT** issue CLOS-MACRO-COMPILATION, version 2
This issue is still under discussion. There has been a lot of talk
about how this relates to the creation of meta-objects at compile
time, but the only proposals that have been made so far are the two
included here.
Forum: Compiler
Issue: CLOS-MACRO-COMPILATION
References: CLOS chapters 1 & 2 (88-002R)
CLOS chapter 3 (89-003)
Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Issue DEFINING-MACROS-NON-TOP-LEVEL
Category: CLARIFICATION
Edit History: V1, 10 Mar 1989, Sandra Loosemore
V2, 13 Mar 1989, Sandra Loosemore
Status: **DRAFT**
Problem Description:
Do the CLOS defining macros (DEFCLASS, DEFMETHOD, DEFGENERIC, and
DEFINE-METHOD-COMBINATION) have compile-time side-effects similar
to those for DEFSTRUCT or DEFMACRO?
A part of the problem is that we do not currently have a full
understanding of all the issues involved. In particular, work on
defining the CLOS meta-object protocol is still in progress. The goal
of this proposal is to say enough about the behavior of these macros
in the standard so that users can use them portably in compiled code,
but to leave as much of the behavior as possible unspecified to avoid
placing undue restrictions on the meta-object protocol.
There are two proposals, MINIMAL and NOT-SO-MINIMAL.
Proposal CLOS-MACRO-COMPILATION:MINIMAL:
State that top-level calls to the CLOS defining macros have the
following compile-time side-effects. Any other compile-time behavior
is explicitly left unspecified.
DEFCLASS:
* The class name becomes a type specifier which may appear in
subsequent type declarations.
* The class name can be used to name a superclass in a subsequent
DEFCLASS.
* The class name can be used as a specializer in a subsequent
DEFMETHOD.
DEFGENERIC:
* The generic function can be referenced in a subsequent DEFMETHOD.
* The generic function is not callable at compile-time.
DEFMETHOD:
* The method is not callable at compile-time. If there is a generic
function with the same name at compile-time, compiling a DEFMETHOD
will not add the method to that generic function. The compiler may
perform tests for lambda-list congruence only between the DEFGENERICs
and DEFMETHODs for a given generic function name that appear within
the file being compiled, and not against a generic function of the
same name which exists in the compile-time environment.
DEFINE-METHOD-COMBINATION:
* The method combination can be used in a subsequent DEFGENERIC. If it
is referenced, the body of a long form of method combination must be
evaluable at compile-time.
Rationale:
The compile-time behavior of DEFCLASS is similar to DEFSTRUCT or
DEFTYPE.
DEFGENERIC and DEFMETHOD are similar to DEFUN, which doesn't add the
function definition to the compile-time environment. Since generic
functions may be freely redefined between compile and run time (just
like any other function), a method may end up "belonging" to a
different generic function at load time than at compile time.
Some implementations compose effective methods at compile time, which
requires evaluating the body of the DEFINE-METHOD-COMBINATION at
compile time.
Proposal CLOS-MACRO-COMPILATION:NOT-SO-MINIMAL:
This is the same as proposal MINIMAL, except under DEFCLASS add:
* The class may be instantiated at compile-time. Provided the
appropriate methods are also defined at compile-time, this implies:
- The class can be used as the :METACLASS option of a later DEFCLASS.
- It can be used as the :GENERIC-FUNCTION-CLASS or :METHOD-CLASS option
of a DEFGENERIC, GENERIC-FUNCTION, GENERIC-FLET, or GENERIC-LABELS.
Rationale:
Being able to instantiate a class at compile-time is somewhat more
convenient for users.
Current Practice:
The items listed under DEFCLASS in proposal MINIMAL are fairly standard
programming style.
Flavors does not support compile-time instantiation of classes. It
does not make method combinations available at compile-time either, but
Moon considers that to be a bad design choice.
Cost to implementors:
Unknown.
Cost to users:
Unknown, but probably fairly small.
Note that for proposal NOT-SO-MINIMAL, users still have to ensure that
any methods on the class which may be invoked at compile-time are
fully defined. This includes the INITIALIZE-INSTANCE and
SHARED-INITIALIZE methods that are invoked by MAKE-INSTANCE.
Wrapping an (EVAL-WHEN (EVAL COMPILE LOAD) ...) around the appropriate
definitions will make sure they are fully defined at compile-time.
Alternatively, the definitions could be placed in a separate file,
which is loaded before compiling the file that depends on those
definitions.
Benefits:
Programmers can rely on programs that use the CLOS defining macros
being able to compile correctly in all implementations, without having
to wrap explicit EVAL-WHENs around every macro call.
Discussion:
This writeup is based on discussions between Moon, Gray, and
Loosemore, who are mostly in agreement on the things presented in
proposal MINIMAL. We have purposely avoided saying anything about
whether meta-objects representing the classes, methods, etc. get
created at compile-time, or whether such meta-objects are fully or
partially defined. The basic questions addressed by this issue are
what kinds of things can be defined and then used during compilation
of the same file that defines them, and what restrictions might apply.
These proposals are not completely compatible with the meta-object
protocol document (89-003). Gregor Kiczales says:
No one believes that what is written in draft 10 of the MOP is valid.
Sandra Loosemore says:
Although I admit I don't understand all of the issues involved with
the meta-object protocol, I prefer proposal MINIMAL over
NOT-SO-MINIMAL. I don't think leaving the issue of whether or not
classes can be instantiated at compile-time unspecified places an
undue burden on users, and it does leave more freedom for the
meta-object protocol to decide what the right behavior really is.
Dick Gabriel notes:
The question I have about the process going on with respect to the
CLOS-MACRO-COMPILATION issue is whether the fine-grained behavior of
CLOS under various compilation/evaluation situations is being
over-specified.
At this stage of the game I worry that we might go a little too far in
one direction in specification when we are actually engaged in design
work. This isn't intended to be a criticism of any committees, but I
would feel a lot more comfortable with a conservative specification
that defined well-formed programs being loaded or compiled in fresh
Common Lisps with a pretty simple eval-when model that is easier to
specify and which makes it easy for all but the hairiest
compilation-environment-frobbing programs to be written.
∂13-Mar-89 1452 X3J13-mailer issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 14:52:29 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA07899; Mon, 13 Mar 89 15:50:10 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02499; Mon, 13 Mar 89 15:50:07 -0700
Date: Mon, 13 Mar 89 15:50:07 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903132250.AA02499@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
Forum: Compiler
Issue: COMPILE-ENVIRONMENT-CONSISTENCY
References: CLtL p. 68-69, 143, 321
RAM's "Compiler Cleanup Proposal #3"
Category: CLARIFICATION
Edit History: V1, 2 Sep 1988, Sandra Loosemore (initial draft)
V2, 9 Sep 1988, Sandra Loosemore (incorporate suggestions)
V3, 26 Oct 1988, Sandra Loosemore (add suggestion from Benson)
V4, 08 Mar 1989, Sandra Loosemore (wording changes)
Problem Description:
CLtL does not clearly specify what aspects of the compiletime
environment the compiler (or other preprocessor) may "wire in" to code
being compiled. At what time (compiletime or runtime) are certain
kinds of definitions "captured"? What happens if these definitions
are not consistent at both compile and run times?
Proposal COMPILE-ENVIRONMENT-CONSISTENCY:CLARIFY:
The process of compilation causes certain kinds of information present
in the compiletime environment to be captured and incorporated into
the resulting compiled code. Other kinds of information may not be
captured until the compiled code is actually run.
Specifically:
(1) The following information *must* be present in the compiletime
environment for the program to be compiled correctly. This
information need not also be present in the runtime environment.
(a) In conforming code, macros referenced in the code being compiled
must have been previously defined in the compiletime environment.
The compiler must treat any form that is a list beginning with
a symbol that does not name a macro or special form as a function
call. (This implies that SETF methods must also be available at
compiletime.)
(b) In conforming code, variables that are intended to be bound
specially must be declared SPECIAL in the compiletime environment
before any bindings of that variable are processed by the compiler.
The compiler must treat any binding of an undeclared variable as a
lexical binding.
(2) The compiler *may* incorporate the following kinds of information
into the code it produces, if the information is present in the
compiletime environment and is referenced within the code being
compiled. Except where some other behavior is explicitly stated, when
the compiletime and runtime definitions are different, it is
unspecified which will prevail within the compiled code. In all
cases, the absence of the information at compiletime is not an error,
but its presence may enable the compiler to generate more efficient
code.
(a) The compiler may assume that functions that are defined and
declared INLINE in the compiletime environment will retain the
same definitions at runtime.
(b) The compiler may assume that, within a named function, a
recursive call to a function of the same name refers to the
same function, unless that function has been declared NOTINLINE.
(c) COMPILE-FILE may assume that, in the absence of NOTINLINE
declarations, a call within the file being compiled to a named
function which is defined in that file refers to that function.
(This permits "block compilation" of files.) The behavior of
the program is unspecified if functions are redefined individually
at runtime.
(d) The compiler may assume that the signature (or "contract") of
all built-in Common Lisp functions will not change. In addition,
the compiler may treat all built-in Common Lisp functions as if
they had been proclaimed INLINE.
(e) The compiler may assume that the signature (or "contract") of
functions with FTYPE information available will not change. (See
issue FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS.)
(f) The compiler may "wire in" the values of symbolic constants
that have been defined with DEFCONSTANT in the compiletime
environment.
(g) The compiler can assume that type definitions made with DEFTYPE
or DEFSTRUCT in the compiletime environment will retain the same
definition in the runtime environment. It may also assume that
a class defined by DEFCLASS in the compiletime environment will
be defined in the runtime environment in such a way as to have
the same superclasses and metaclass. This implies that
subtype/supertype relationships of type specifiers will not
change between compiletime and runtime. (Note that it is not
an error for an unknown type to appear in a declaration at
compiletime, although it is reasonable for the compiler to
emit a warning in such a case.)
(h) The compiler may assume that if type declarations are present
in the compiletime environment, the corresponding variables and
functions present in the runtime environment will actually be of
those types; otherwise, the runtime behavior of the program is
undefined.
(3) The compiler *must not* make any additional assumptions about
consistency between the compiletime and runtime environments. In
particular:
(a) The compiler may not assume that functions that are defined
in the compiletime environment will retain the either the
same definition or the same signature at runtime, except
in situations (2a) through (2e) above. It is, however,
permissible for the compiler to emit warning messages when
compiling calls to functions that are defined in the compiletime
environment, but where the wrong number or type of arguments
are supplied.
(b) The compiler may not signal an error if it sees a call to a
function that is not defined at compiletime, since that function
may be provided at runtime. Again, it is permissible for the
compiler to emit a warning in these situations.
Rationale:
This proposal generally reflects current practice.
Current Practice:
There don't seem to be any compilers around that do not implement the
provisions of item (1).
For item (2), most compilers (including Lucid) optimize self-recursive
calls by default. Most compilers also opencode data structure
accessors (such as CAR) at some level of optimization, and some code
much more complicated built-in functions inline as well. VaxLisp, for
example, normally compiles MEMBER inline. The Lucid compiler makes
use of type declarations to perform generic-to-specific
transformations on many arithmetic and sequence functions, which is
also a form of inlining. KCL performs block compilation by default,
and Lucid does so under certain conditions.
Cost to implementors:
Unknown, but probably minor.
Cost to users:
Since most implementations appear to be largely in conformance with the
proposal, users should notice little difference.
Benefits:
The presence of a definite specification of what may happen when will
help users structure their programs so they will compile correctly in
all Common Lisp implementations.
Discussion:
Most of the discussion on this issue has been centered on the
terminology describing error situations for item (2). In most cases
where there is an inconsistency between compile-time and run-time, the
results will be unpredictable but harmless. The major exception is
violation of type declarations, which is a "crash-and-burn" error in
many implementations.
There has also been some concern raised that item (3) would prohibit
such things as a cross-compiler that produces standalone programs in
an environment that disallows redefinition of functions. The intent
of this proposal is not to prohibit a compiler from having a magic
switch that imposes additional restrictions on the programs it
compiles, but such a compiler would not be a compiler for Common Lisp.
Several people have expressed reservations about items 2b and 2c, saying
that self-tail-recursion optimization and block compilation should not
be the default behavior of the compiler. Gail Zacharias responds:
This item [2c] has nothing to do with whether anybody does it by
default. The question is whether an end user can take a Common Lisp
program whose internals he's not familiar with, block-compile it, and
be guaranteed that it will continue to function correctly. This item
says that yes, a correct CL program must explicitly indicate what
functions in the source it will redefine at runtime. I don't think
this places such a great burden on the programmer. Without this
provision, only somebody intimately familiar with a program could know
whether it can be safely block-compiled, making block-compilation
useless in the context of portable CL programs.
This thing about "block compilation shouldn't be the default" seems to
come up every time this item is discussed. That's an environment
question and is not addressed by the proposal. The proposal simply
says that block compilation should be legal.
∂13-Mar-89 1514 X3J13-mailer issue COMPILE-FILE-SYMBOL-HANDLING, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:14:36 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA08718; Mon, 13 Mar 89 16:12:23 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02542; Mon, 13 Mar 89 16:12:19 -0700
Date: Mon, 13 Mar 89 16:12:19 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903132312.AA02542@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue COMPILE-FILE-SYMBOL-HANDLING, version 2
Forum: Compiler
Issue: COMPILE-FILE-SYMBOL-HANDLING
References: CLtL p. 182
Issue IN-PACKAGE-FUNCTIONALITY
Issue CONSTANT-COMPILABLE-TYPES
Issue DEFPACKAGE (passed)
Category: CHANGE/CLARIFICATION
Edit History: V1, 01 Feb 1989, Sandra Loosemore
V2, 12 Mar 1989, Sandra Loosemore (discussion, error terms)
Status: Ready for release
Problem Description:
It is not clear how COMPILE-FILE is supposed to specify to LOAD how
symbols in the compiled file should be interned. In particular, what
happens if the value of *PACKAGE* is different at load-time than it
was at compile-time, or if any of the packages referenced in the file
are defined differently?
There are three proposals: CURRENT-PACKAGE, HOME-PACKAGE, and
REQUIRE-CONSISTENCY.
Proposal COMPILE-FILE-SYMBOL-HANDLING:CURRENT-PACKAGE:
When a compiled file is loaded, the interned symbols it references
are found by the following procedure. The rules are applied in the
order listed and only the first applicable rule has any effect.
(1) Any symbol accessible at compile time in the package that is the
value of *PACKAGE* is found by calling INTERN at load time with one
argument, the name of the symbol.
(2) A keyword symbol is found by finding or creating a keyword symbol
with the same name.
(3) A symbol that at compile time is an external symbol of its home
package is found at load time by finding the package with the same
name as the compile-time home package, and then finding an exported
symbol of that package with the same name as the compile-time symbol.
If no such package exists, no such symbol exists, or the symbol is not
exported, an error is signalled.
(4) Any other symbol is found by calling INTERN at load time with two
arguments, the name of the symbol and the package with the same name
as the compile-time symbol's home package. If no such package exists,
an error is signalled.
The goal of this procedure is for each symbol reference to be
resolved to the same symbol when a compiled file is loaded as when
the source file is loaded directly with LOAD. It is possible to
create package structures that make that impossible; for example, it
is possible for a symbol to be inaccessible from its own home
package. A conforming program cannot depend on any symbol
resolution behavior that is not provided by the above four rules.
If any top level form in a compiled file changes the value of
*PACKAGE*, other than a SELECT-PACKAGE appearing as the first
top level form in the file, the package in which the loader will
place the constant symbols referenced in the file is unspecified.
Rationale:
Proposal CURRENT-PACKAGE makes COMPILE-FILE/LOAD follow the same
rules as PRINT/READ. For any symbol not written with a package
prefix in the source file (which should be the great majority of
them), CURRENT-PACKAGE will make loading the compiled file get the
same symbols as loading the source file.
The reason for the rule about changing the value of *PACKAGE* is that
many loaders cache the interning of symbols; if the same symbol
appears multiple times in the source file, its name may only be
looked up once at load time. Since not all loaders are required to
work this way, changing *PACKAGE* in mid-file is not allowed,
because the effect on later occurrrences of a symbol would be
implementation-dependent.
Proposal COMPILE-FILE-SYMBOL-HANDLING:HOME-PACKAGE:
When a compiled file is loaded, the interned symbols it references are
found by calling INTERN at load time with two arguments, the name of
the symbol and the package with the same name as the compile-time
symbol's home package. If no such package exists, an error is
signalled.
The goal of this procedure is for each symbol reference to be resolved
to the same symbol when a compiled file is loaded as when the source
file was processed by COMPILE-FILE. A conforming program cannot
depend on any symbol resolution behavior that is not provided by the
above rule.
If any top level form in a compiled file changes the value of
*PACKAGE* when the file is loaded interpretively but not during
compile-time processing by COMPILE-FILE, the package in which the
loader will place the constant symbols referenced in the file is
unspecified.
Rationale:
The behavior specified in this proposal is simple and easy to
understand (there is only one rule to remember instead of four).
It does not require any restrictions on where top-level
SELECT-PACKAGE forms may appear in the file. It allows a compiled
file that does not include an explicit SELECT-PACKAGE to be loaded
successfully no matter what the load-time value of *PACKAGE* is,
as long as the compile-time value of *PACKAGE* was the "right"
package.
Proposal COMPILE-FILE-SYMBOL-HANDLING:REQUIRE-CONSISTENCY:
In order to guarantee that compiled files can be loaded correctly,
users must ensure that the packages referenced in the file are defined
consistently at compile and load time. Conforming Common Lisp programs
must satisfy the following requirements:
(1) The value of *PACKAGE* when the contents of the file are compiled
by COMPILE-FILE must be the same as the value of *PACKAGE* when
the file is loaded. In particular:
(a) If any top level form in a compiled file changes the value
of *PACKAGE*, other than a SELECT-PACKAGE appearing as the first
top-level form in the file, the package in which the loader
will place the constant symbols referenced in the file is
unspecified.
(b) If the first top-level form in the file is not a call to
SELECT-PACKAGE, then the value of *PACKAGE* at the time LOAD is
called must be a package with the same name as the package that
was the value of *PACKAGE* at the time COMPILE-FILE was called.
(2) For all symbols that were accessible in *PACKAGE* at compile
time but whose home package was another package, at load time there
must be a symbol with the same name that is accessible in both the
load-time *PACKAGE* and in the package with the same name as the
compile-time home package.
(3) For all symbols in the compiled file that were external symbols in
their home package at compile time, there must be a symbol with the
same name that is an external symbol in the package with the same name
at load time.
If any of these conditions do not hold, the package in which LOAD looks
for the affected symbols is unspecified. Implementations are permitted
to signal an error or otherwise define this behavior.
Otherwise, when a compiled file is loaded, the interned symbols it
references are found by calling INTERN at load time with two
arguments, the name of the symbol and the package with the same name
as the compile-time symbol's home package. If no such package exists,
an error is signalled.
Rationale:
Any program that behaves differently under the other two proposals
is already nonportable. This proposal is merely an explicit
statement of the status quo, namely that users cannot depend on
any particular behavior if the package environment at load time is
inconsistent with what existed at compile time.
Current Practice:
PSL/PCLS implements something very similar to proposal HOME-PACKAGE,
as does A-Lisp. Utah Common Lisp implements something like proposal
CURRENT-PACKAGE, but the chief compiler hacker says he thinks that
proposal HOME-PACKAGE actually makes more sense, and agrees that any
program that behaves differently under the two proposals is broken.
The TI Explorer currently implements proposal HOME-PACKAGE, after
trying it both ways.
KCL implements something like HOME-PACKAGE (symbols in the compiled
file are explicitly qualified with the name of their home package),
except that it differentiates between internal and external symbols.
Lucid Lisp appears to implement something like proposal CURRENT-PACKAGE.
Symbolics Genera implements CURRENT-PACKAGE. Symbolics Cloe probably
does also.
Coral also implements something like proposal CURRENT-PACKAGE.
Cost to implementors:
Proposals HOME-PACKAGE and CURRENT-PACKAGE would be incompatible
changes for implementations that currently do things the other way.
It would probably be easier to convert to HOME-PACKAGE than
CURRENT-PACKAGE, since it is less complicated.
Proposal REQUIRE-CONSISTENCY is intended to be compatible with either
of the other two proposals, but it may not be entirely compatible with
the details of current implementations.
Cost to users:
Proposal HOME-PACKAGE places the fewest restrictions on user programs.
Proposal CURRENT-PACKAGE places a restriction on where and how the value
of *PACKAGE* may be changed within the file.
Proposal REQUIRE-CONSISTENCY places even more restrictions on user
programs.
Most of these restrictions are probably already necessary in portable
programs. However, some nonportable programs that depend on the "other"
model may be broken by proposals HOME-PACKAGE or CURRENT-PACKAGE.
For a discussion of how these proposals treat nonportable or erroneous
programs, see the "Analysis" section below.
Benefits:
COMPILE-FILE's treatment of symbols is made explicit in the standard.
Analysis:
Proposals CURRENT-PACKAGE and HOME-PACKAGE present two different
models of how this problem might be solved. Essentially, proposal
CURRENT-PACKAGE uses the same rules as PRINT/READ in deciding when to
qualify symbols with a package name and where to find unqualified
symbols. Proposal HOME-PACKAGE requires -all- symbols written to the
compiled file to be qualified with an explicit package, and the loader
simply INTERNs the symbol names in that package.
These two proposals differ in the following situations. Proposal
REQUIRE-CONSISTENCY, in effect, says that valid programs do not cause
any of these situations to occur, and the behavior in such cases is
unspecified (allowing both models to be used as valid implementation
techniques).
(1) The situation where the file does not contain a SELECT-PACKAGE
and where the compile-time value of *PACKAGE* is a package with a
different name than the load-time value of *PACKAGE*.
Proposal CURRENT-PACKAGE would intern the names of symbols that
were accessible in *PACKAGE* at compile time in *PACKAGE* at load time.
Proposal HOME-PACKAGE would intern the names of symbols that
were accessible in *PACKAGE* at compile time in the package with
the same name as their compile-time home package.
In general, programs must be compiled in the "right" package, so
that the compiler can find and apply the correct macro expansions,
type definitions, and so on; see issue COMPILE-ENVIRONMENT-CONSISTENCY.
As a result of macroexpansion or other transformations applied by
the compiler, the compiled file may contain symbol references that
were not present in the source file. Proposal CURRENT-PACKAGE may
cause problems because these references may be resolved to be
symbols other than the ones that were intended. Since proposal
HOME-PACKAGE remembers the home package of all symbols, it is much
more likely to find the correct symbols at load time.
(2) The situation where *PACKAGE* is altered by a top-level form
that is not a SELECT-PACKAGE which is the first top-level form in
the file.
Proposal CURRENT-PACKAGE says this is illegal. This is because
of the difficulty in deciding what the "current package" is, if it
is allowed to change throughout the file.
Proposal HOME-PACKAGE says this is OK, as long as *PACKAGE* is
altered in the same way at compile time as when the file is loaded
interpretively. This is possible because the behavior this
proposal specifies does not depend on what the value of *PACKAGE*
is once symbols in the source file have been read by COMPILE-FILE.
Some people argue that allowing *PACKAGE* to be switched in
mid-file is a bad idea anyway; it is not really necessary and it
implies a restriction on COMPILE-FILE to read forms from the file
one at a time, processing each form before the next call to READ.
Others argue that restricting SELECT-PACKAGE to be the first
top-level form is an artificial contrivance. The compile-time
behavior of SELECT-PACKAGE is well-defined no matter where it
appears in the file. There is also a problem defining what "the
first top-level form" really means. Finally, this model requires
all package definitions to be made externally to the file, which
may be inconvenient for smaller programs that now contain the
package definition and package contents all in one file.
(3) The situation where there is a symbol accessible in the
compile-time value of *PACKAGE* but with another home package, and
where at load time there is not a symbol with the same name that
is accessible in both packages. This situation might occur, for
example, if at compile time there is a symbol that is external in
its home package and that package is used by *PACKAGE*, but where
there is no such external symbol in that package at load time, or
the load-time *PACKAGE* does not use the other package.
Proposal CURRENT-PACKAGE would find or create a symbol accessible
in *PACKAGE*.
Proposal HOME-PACKAGE would find or create a symbol accessible in
a package with the same name as the symbol's compile-time home
package.
Some people feel that the behavior of proposal CURRENT-PACKAGE is
more intuitive in this situation, and that it is more forgiving of
differences between the compile-time and load-time package
structures. Others feel that the behavior of HOME-PACKAGE is more
intuitive, and that if there have been significant changes to the
package structures, it is probably an indication that the file
needs to be recompiled anyway, since the compiler might have
picked up macro definitions and the like from the wrong package.
(4) The situation where a symbol is external in its home package
and where there is no such external symbol in that package at load
time.
Proposal CURRENT-PACKAGE would quietly find or create the symbol
in *PACKAGE* if the symbol were accessible in *PACKAGE* at compile
time. Otherwise, it will signal an error.
Proposal HOME-PACKAGE would always just quietly find or create the
symbol as internal in its home package.
Not complaining when a symbol that is supposed to be external
isn't can be seen as a violation of modularity. However, it seems
like this argument should apply equally to symbols whose home
package is *PACKAGE* as symbols whose home package is somewhere
else.
Discussion:
Loosemore is opposed to proposal CURRENT-PACKAGE, but would be
less opposed to it if it contained an explicit statement that
*PACKAGE* must be a package with the same name at load time as at
compile time. She thinks proposal HOME-PACKAGE is the best of the
options presented here.
Moon is opposed to proposal HOME-PACKAGE, but would be less
opposed to it if it required an error to be signalled when a
symbol that was external at compile time is not external at load
time. He thinks proposal CURRENT-PACKAGE is the best of the options
presented here.
John Kolts, who did the implementation on the TI Explorer, recalls:
My primary motivation was compile/load consistency. I thought it was
important that during loading all symbol references should resolve to
the same symbol as they would have during the compilation. If, for
instance, the packages used by *package* were different at compile
time than at load time, my approach would still intern the accessible
symbols in the "right" package during loading. [...] Of course, such
an approach means that loading the [compiled file] could give results
incompatible with loading the LISP file directly, but I felt that if
behavior consistent with some altered package structure was desired,
the file should be recompiled, a relatively small price to pay for the
benefit of this consistency.
A related consideration was that remembering the home package seemed to
be important for proper macro expansion in certain cases.
What was apparent was that there were several defensible approaches,
none of which was obviously the absolutely right way to handle certain
pathological situations. Making the expected behavior explicit in a
standard is a good idea.
David Gray says:
There really shouldn't be anything wrong about using SELECT-PACKAGE
multiple times within a file as long as it is used at top level so
that the compiler knows that the current package is being changed.
Cris Perdue says:
[Proposal HOME-PACKAGE] doesn't ensure that the home package remains
the same across compilation and loading, which I consider the key
consideration. How about this statement instead?
"When a file is compiled, the symbol name is recorded together
with the home package name and an indication of whether the
symbol is external in its home package. At load time the
symbol is effectively looked up with:
(find-symbol string (find-package pkg-name))
If the symbol is noted as external, it must be found at load
time as :external. If it is noted as internal, it must either
be present in the package or not found at all. If it is not found
at all, it is created as if by:
(intern string (find-package pkg-name))
If the package system is not in a suitable state, an error is
signalled."
This is what I consider "the right thing".
JonL White says:
I don't believe we have anything to gain at this point in trying to
standardize the faslout package-qualification algorithm; this is
notwithstanding that standardizing PRINT output, as an interchange
format, is an absolute requirement [even though READ-of-PRINT will
likely be even more information losing than loading in a compiled
file!]
∂13-Mar-89 1517 X3J13-mailer issue COMPILER-LET-CONFUSION, version 7
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:16:50 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA08737; Mon, 13 Mar 89 16:14:30 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02546; Mon, 13 Mar 89 16:14:26 -0700
Date: Mon, 13 Mar 89 16:14:26 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903132314.AA02546@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue COMPILER-LET-CONFUSION, version 7
Issue: COMPILER-LET-CONFUSION
Forum: Compiler
References: CLtL p. 112
Category: CHANGE
Edit History: V1, 27 Sep 1988, Sandra Loosemore (initial version)
V2, 04 Oct 1988, Sandra Loosemore (add another example)
V3, 31 Oct 1988, Sandra Loosemore (only proposal ELIMINATE)
V4, 08 Jan 1989, Kent M. Pitman (new alternative)
V5, 09 Jan 1989, Sandra Loosemore (discussion)
V6, 08 Mar 1989, Sandra Loosemore (general updating)
V7, 13 Mar 1989, Sandra Loosemore (fix bug from V6)
Problem Description:
The description of the COMPILER-LET special form in CLtL is confusing
to many people. There are no examples provided to make it clear how it
is supposed to be used. The only description which is offered is overly
concrete, which has led to confusion about the intent of COMPILER-LET,
and about its implementability.
The intent of COMPILER-LET was to permit information to be communicated
between macros by use of dynamic variables at macroexpansion time.
It was not necessary to the intended uses of COMPILER-LET that such
variables ever be bound at execution time.
Unfortunately, probably because some implementations did not primitively
support COMPILER-LET at the time CLtL was written, an exception was
permitted to make COMPILER-LET `more or less work' in interpreters:
the COMPILER-LET variables were permitted to be bound at execution time.
The problem was further compounded by the fact that CLtL presented this
exception as part of COMPILER-LET's contract rather than as an
implementation note, and by the fact that no examples of actually using
COMPILER-LET correctly are provided.
One particular case where problems have resulted is a situation like
(compiler-let ((*v* 1))
#'(lambda () (m)))
where M is a macro that refers to *V*. In some implementations, M is
not macroexpanded until the dynamic extent of the *V* binding has
ended.
Subtle bugs can be introduced because of the different handling of the
variable bindings in the interpreter and the compiler. In compiled
code, the bindings are only lexically visible during the expansion of
macros at compile time, while in interpreted code the bindings have
dynamic scope and may also be seen during ordinary evaluation if
evaluation and macroexpansion happen "in parallel".
Further compatibility problems can result from the value forms being
evaluated in a null lexical environment in the compiler and the ordinary
lexical environment in the interpreter.
Background and Analysis:
It should be clear up front that COMPILER-LET is not computationally
essential. Most (if not all) uses of it can be rewritten using MACROLET
or SYMBOL-MACROLET.
A typical use of COMPILER-LET might be:
(defvar *local-type-declarations* '())
(defmacro local-type-declare (declarations &body forms)
`(compiler-let ((*local-type-declarations*
(append ',declarations *local-type-declarations*)))
,@forms))
(defmacro typed-var (var)
(let ((type (assoc var *local-type-declarations*)))
(if type `(the ,(cadr type) ,var) var)))
(defun f (x y)
(local-type-declare ((x fixnum) (y float))
(+ (typed-var x) (typed-var y))))
The same thing could be accomplished using MACROLET:
(defmacro local-type-declare (declarations &body forms)
(local-type-declare-aux declarations forms))
(defmacro typed-var (var) var)
(eval-when (eval compile load)
(defun local-type-declare-aux (declarations forms)
`(macrolet ((typed-var (var)
(let ((type (assoc var ',declarations)))
(if type `(the ,(cadr type) ,var) var)))
(local-type-declare (new-declarations &body new-forms)
(local-type-declare-aux
(append new-declarations ',declarations)
new-forms)))
,@forms)))
A further alternative would be to use SYMBOL-MACROLET (this particular
implementation assumes that issue DEFINING-MACROS-NON-TOP-LEVEL passes):
(let ((temp (gensym)))
(defmacro local-type-declare (declarations &body forms &environment env)
`(symbol-macrolet ((,temp ',(append declarations
(symbol-macro-value temp env))))
,@forms))
(defmacro typed-var (var &environment env)
(let ((type (assoc var (symbol-macro-value temp env))))
(if type `(the ,(cadr type) ,var) var)))
)
(defun symbol-macro-value (symbol env &optional default)
(multiple-value-bind (expansion macro-p) (macroexpand symbol env)
(if macro-p (eval expansion) default)))
Opinion is divided as to which is more understandable. Some
people find the COMPILER-LET idiom more understandable (assuming that
it can be made to work consistently in compiled and interpreted
code), while others find it just as natural to use MACROLET or
SYMBOL-MACROLET.
The issues are these:
- Is it possible to implement COMPILER-LET in a usefully consistent
way in all implementations?
- Are the benefits of providing a useful and compatible implementation
of COMPILER-LET worth any associated cost?
Two proposals are presented below:
- Option REPAIR argues that COMPILER-LET provides interesting
functionality that can be implemented in a manner that is usefully
consistent across implementations, and that the associated cost
is low enough for it to be worthwhile to do so.
- Option ELIMINATE argues that COMPILER-LET complicates the language
and that providing this construct is not worth the associated
implementation cost.
Proposal (COMPILER-LET-CONFUSION:REPAIR):
Strike the existing definition of COMPILER-LET. Redefine it as follows:
COMPILER-LET [Special form]
COMPILER-LET is similar to LET, but it always makes special
bindings and makes those bindings visible only during
macroexpansion of forms in the body, not during the runtime
execution of those forms.
The intent is that some macros might macroexpand into calls to
COMPILER-LET in which the body would the contain references to
macros which access the variables in the COMPILER-LET.
The initial value forms of the bindings, if any, are always
evaluated in a null lexical context, regardless of whether the
COMPILER-LET expression is being interpreted or compiled.
The initial value forms of the bindings, if any, are evaluated in
a dynamic context where the bindings of any lexically enclosing
COMPILER-LET are visible, and where dynamic execution-time
environment may or may not be visible.
Implementation Note: Permitting the execution-time dynamic
environment to be visible when initializing COMPILER-LET variables
is a concession to some interpreters which may have to do this in
order to keep the cost down. Where feasible, implementors should
try not to make the runtime environment visible.
Rationale:
This gives a consistent description of COMPILER-LET which separates
issues of intent from those of implementation in a way that makes it
possible for portable code to make serious use of it, and which does
not force gratuitous incompatibilities between interpreters and
compilers.
This description of COMPILER-LET can be implemented without undue
cost by all implementations. See "Cost to Implementors" for details.
Cost to Implementors:
Modest, but nontrivial in some implementations.
In compiled code, and in interpreters doing a one-time semantic
prepass, it should be fairly easy for COMPILER-LET to cause the
variables to get bound (using PROGV) during semantic analysis.
In interpreters which do not do a semantic-prepass, it is necessary
to fully macroexpand the body. Assuming the presence of a
SYSTEM::MACROEXPAND-ALL primitive, the definition of COMPILER-LET
could look like:
(DEFMACRO COMPILER-LET (BINDINGS &BODY FORMS &ENVIRONMENT ENV)
(SETQ BINDINGS ;; Assure no non-atom bindings
(MAPCAR #'(LAMBDA (BINDING)
(IF (ATOM BINDING) (LIST BINDING) BINDING))
BINDINGS))
(PROGV (MAPCAR #'CAR BINDINGS)
(MAPCAR #'CDR BINDINGS)
(SYSTEM::MACROEXPAND-ALL `(PROGN ,@FORMS) ENV)))
This reduces the problem of writing a program capable of doing a
full macroexpansion. Many systems already have such a facility.
Pitman wrote such a facility in Cloe Runtime in order support
SYMBOL-MACROLET (before it was christened a special form); it was
about 750 lines of relatively straightforward, well-commented code.
Cost to Users:
Code currently depending on this feature is either non-existent or
already not portable (due to wide variation in implementation
strategy for COMPILER-LET).
Most users will probably be happy for any interpretation which offers
them a future shot at portability.
Some users have indicated they dislike interpreters which do a semantic
prepass, because they like to be able to dynamically redefine macros
while debugging.
Proposal (COMPILER-LET-CONFUSION:ELIMINATE):
Remove COMPILER-LET from the language.
Rationale:
Some people think that having one less special form would simplify the
language. The revised COMPILER-LET semantics, which require
COMPILER-LET to make special bindings which are only visible during
expansion of macros which appear lexically within its body, are
not shared by any other feature in the language, and require a
fairly complex implementation technique. There are other
constructs which are strictly lexical that can be readily used
to solve the same kinds of problems that COMPILER-LET is intended to
be used for.
Cost to Implementors:
Minimal. Implementations could continue to support COMPILER-LET as
an extension.
Cost to Users:
Code currently depending on this feature is either non-existent or
already not portable (due to wide variation in implementation
strategy for COMPILER-LET).
People who use COMPILER-LET would have to rewrite their programs to use
some other construct. As discussed above, most uses of COMPILER-LET
for communication between macros can be handled using MACROLET or
SYMBOL-MACROLET, though some perspicuity may be lost in the process.
Current Practice:
Some implementations have implemented the description in CLtL.
Users of those implementations (quite reasonably) can't figure how to
use COMPILER-LET and so don't use it much.
Some implementations (the ones from which COMPILER-LET originally came)
continue to use their pre-CLtL semantics. These semantics are useful, though
incompatible with CLtL (which they largely consider to simply be in error).
Users of those implementations probably use COMPILER-LET somewhat more
often since it has an intelligible behavior, but their code is not portable
since it relies on behaviors which are either contrary to or not guaranteed
by CLtL.
Benefits:
Either way, a potential area of incompatibility between compiled and
interpreted code would be eliminated.
Either way, a potential area of portability trouble would be very
drastically reduced (in the case of the REPAIR option) or eliminated
(in the case of the ELIMINATE option).
Discussion:
Pitman strongly favors COMPILER-LET-CONFUSION:REPAIR. He argues
against the idea of using MACROLET instead of COMPILER-LET, saying:
This is a little misleading because it's like saying you can
do without LET given that you have FLET. You can, but you lose some things
in the process:
Just as rewriting a LET using FLET might slow your computation, so too
a rewrite of COMPILER-LET using MACROLET might slow things down. However,
compilation speed is generally not weighted as heavily as execution speed
by many people, so the loss of speed here may not be as important.
Just as rewriting a LET using FLET might obscure the simplicity of your
intent, so too rewriting COMPILER-LET using MACROLET might obscure your
intent. You'd probably get used to recognizing idioms if you used it often
enough. Certainly this would be true if you didn't have LET. However,
COMPILER-LET is used less often, so not having it would mean that the
code you wrote instead would be much harder to read because people
wouldn't have the necessary familiarity with the idioms involved and so
wouldn't always understand them.
Sandra Loosemore responds:
The argument that using MACROLET is more inefficient than COMPILER-LET
is questionable. Both of the suggested implementation techniques for
COMPILER-LET involve considerable overhead.
If COMPILER-LET were not part of the language, people wouldn't think in
terms of rewriting COMPILER-LETs as MACROLETs; instead, they'd think of
how to use MACROLET in the first place to solve their problems. This
is what people who now use implementations with broken COMPILER-LETs
already do. Since MACROLET is now used much more frequently than
COMPILER-LET, that argues that people are much more familiar with
MACROLET idioms than COMPILER-LET idioms.
Also, note that the intent of the revised COMPILER-LET definition is
to make the binding only lexically visible within the body. Using
special binding for this purpose is troublesome. Both the MACROLET
and SYMBOL-MACROLET solutions are completely lexical and avoid all
the problems associated with special binding.
Glenn Burke thinks it needs to be emphasized that the code-walker
mentioned in the REPAIR proposal does not need to be portable. He
says:
The present wording makes it sound like a piece of cake to do with
portable code, when the reality is that a good fraction of CL cleanup
effort has involved the lack of capability of producing such a beast.
Without one or more of a number of proposals being accepted, a fully
correct portable code walker cannot be built, in my belief.
I object to the flippant attitude of just "presupposing" this
"trivial" function which "we know how to do".
∂13-Mar-89 1531 X3J13-mailer **DRAFT** issue DEFCONSTANT-NOT-WIRED, version 6
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:30:56 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA09104; Mon, 13 Mar 89 16:28:40 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02557; Mon, 13 Mar 89 16:28:37 -0700
Date: Mon, 13 Mar 89 16:28:37 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903132328.AA02557@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: **DRAFT** issue DEFCONSTANT-NOT-WIRED, version 6
We don't expect to ask for a vote on this issue -- the writeup is just
being distributed so that we can refer to it in case the issue ever
comes up again. None of the suggestions listed here seemed to have a
great deal of support among people on the cl-compiler list, and all of
them have problems we haven't been able to resolve yet.
Forum: Compiler
Issue: DEFCONSTANT-NOT-WIRED
References: CLtL pages 68-69
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS,
PROCLAIM-LEXICAL,
DECLARE-TYPE-FREE,
DEFCONSTANT-SPECIAL
Category: ADDITION
Edit history: 09 Oct 1988, V1 by David Gray
27 Oct 1988, V2 by David Gray (new proposal)
10 Nov 1988, V3 by David Gray - updated proposal, rationale
and discussion sections in response to comments.
21 Nov 1988, V4 by David Gray - SPECIAL cancels CONSTANT;
CONSTANT doesn't require previous SPECIAL.
28 Nov 1988, V5 by Sandra Loosemore (clean up, fix
some consistency problems)
13 Mar 1989, V6 by Sandra Loosemore (start over)
Status: **DRAFT**
Problem description:
DEFCONSTANT performs two different functions:
- It says that it is an error to SETQ or rebind the variable which
is being defined as a constant.
- It gives the compiler permission to evaluate the initial value form
at compile time, and to build assumptions about the value into
programs being compiled.
In some cases, one would like to have the first behavior without
getting the second. In particular, one would like to get the same
behavior with regard to signalling errors and warnings that you get
with DEFCONSTANT.
Common Lisp provides no mechanism for specifying a variable should
be treated in this way.
Proposal DEFCONSTANT-NOT-WIRED:FIX-DEFPARAMETER:
This is what DEFPARAMETER was supposed to be used for. The description
of DEFPARAMETER needs to be clarified to reflect this, perhaps by
saying that a continuable error should be signalled if an attempt is
made to SETQ or rebind a variable defined with DEFPARAMETER.
Rationale:
DEFPARAMETER apparently derives from Zetalisp's DEFCONST construct,
which was used to indicate that values that would "never" change,
without licensing the compiler to make assumptions about that value.
However, most uses of DEFCONST have apparently been changed to use
DEFCONSTANT instead.
Objections:
Some people don't think that DEFPARAMETER was intended to be used
in this way and that this would be an incompatible change.
Proposal DEFCONSTANT-NOT-WIRED:RESTORE-DEFCONST:
Leave DEFPARAMETER alone but add another construct with the semantics
described above.
Rationale:
Some people don't think that DEFPARAMETER was intended to be used
in this way.
Objections:
We haven't been able to come up with a good name for this construct.
"DEFCONST" is too confusing and all of the other names that have
been suggested are too long. Also, having so many macros for
declaring variables with is confusing.
Proposal DEFCONSTANT-NOT-WIRED:NEW-DECLARATION:
Add a new CONSTANT declaration to the language which can be used to
declare that a variable cannot be SETQ'd or bound within the scope of
the declaration.
Rationale:
This solves the problem and also provides more general functionality.
For example, one could declare that a lexical variable won't be
SETQ'ed.
Objections:
We haven't been able to decide whether a CONSTANT declaration should
augment or replace a SPECIAL or LEXICAL declaration. How do you
initialize a variable that has been proclaimed CONSTANT? Some people
have objected to calling the declaration CONSTANT unless it is
equivalent to what a DEFCONSTANT does.
Proposal DEFCONSTANT-NOT-WIRED:ADD-OPTIONAL-ARGUMENT:
Add an optional argument to DEFCONSTANT to indicate whether the
compiler can make assumptions about the constant's value.
Rationale:
It would solve the problem.
Objections:
It would make DEFCONSTANT have different syntax from DEFVAR and
DEFPARAMETER.
Proposal DEFCONSTANT-NOT-WIRED:DEFINE-VARIABLE
Define a single macro, DEFINE-VARIABLE, that can be used to do what
DEFVAR, DEFPARAMETER, and DEFCONSTANT now do, plus the proposed new
functionality, plus possibly handle lexical variables as well
(if proposal PROCLAIM-LEXICAL passes). Arguments to the macro
could be used to control whether the value is allowed to change
and whether the compiler is allowed to make assumptions about the
value.
Rationale:
It would solve the problem without cluttering up the language with
new defining macros for every possible combination of behavior.
Objections:
Nobody has proposed anything definite yet.
Discussion:
This issue was discussed at length on the cl-compiler mailing list
last fall, without coming up with an acceptable proposal. It didn't
appear that any of the alternatives had a great deal of support. This
writeup summarizes the alternatives that have been proposed at various
times. Some of them (particularly NEW-DECLARATION) have been
considered in detail, and others (DEFINE-VARIABLE) haven't been
pursued at all.
∂13-Mar-89 1533 X3J13-mailer issue DEFINE-OPTIMIZER, version 5
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:33:36 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA09197; Mon, 13 Mar 89 16:31:22 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02562; Mon, 13 Mar 89 16:31:17 -0700
Date: Mon, 13 Mar 89 16:31:17 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903132331.AA02562@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue DEFINE-OPTIMIZER, version 5
Forum: Compiler
Issue: DEFINE-OPTIMIZER
References: Issue SYNTACTIC-ENVIRONMENT-ACCESS
Category: ADDITION
Edit history: 28-Sep-88, Version 1 by Pitman
10-Mar-89, Version 2 by Pitman (clarifications, new example),
10-Mar-89, Version 3 by Pitman & Loosemore
11-Mar-89, Version 4 by Pitman
13-Mar-89, Version 5 by Loosemore (discussion)
Status: Ready for release
Problem Description:
Often a general functional interface could be bypassed given explicit
knowledge of the arguments passed. This may happen when the arguments
are constant (or otherwise inferrable), an argument type is known (eg,
due to use of THE or DECLARE), or when some particular pattern of
optional, rest or keyword arguments is apparent.
Most implementations provide internally for optimization of generalized
function call interfaces to more specialized ones, but such an
optimization facility is not provided to Common Lisp users.
The absence of this facility in a portable fashion means that some
CL programs run slower than they need to in some implementations, or
else that some operators that should be implemented as functions end
up getting implemented as macros to assure needed efficiency.
Proposal (DEFINE-OPTIMIZER:NEW-FACILITY):
Introduce a facility for declaring compiler optimizations.
DEFINE-OPTIMIZER name arglist {declaration}* {form}* [Macro]
Defines a compiler optimizer for a function named NAME. The ARGLIST,
DECLARATIONS, and FORMS are treated exactly like the arglist,
declarations, and forms in a DEFMACRO. (The arglist may include
&ENVIRONMENT and &WHOLE.)
The argument NAME must name a function which has been previously
defined. The effects of defining an optimizer for a locally or
globally defined macro, a locally defined function, or a special
form are undefined.
When the optimizer is invoked, the forms are executed in the context
of bindings specified by the arglist, and two values are yielded,
RESULT and VALID-P. (If either of the first or second return value
is non-NIL, then the first return value is considered valid).
If the result is valid, it is a form which is preferable to evaluate
instead of the indicated call.
If a call to DEFINE-OPTIMIZER appears at top-level in a file
being processed by the file compiler, it also makes the optimizer
known at compile-time (similar to the way DEFMACRO makes a macro
definition known to the compiler).
OPTIMIZE-EXPRESSION-1 form env [Function]
Similar to MACROEXPAND-1. Invokes the optimizers for the top level of
FORM, but does not iterate on the result. Returns two values:
RESULT and CHANGED-P.
Note: If an optimizer returns a result which is not valid,
OPTIMIZE-EXPRESSION-1 hides the fact by returning FORM,NIL
rather than NIL,NIL.
OPTIMIZE-EXPRESSION form env [Function]
Iterates calling OPTIMIZE-EXPRESSION-1 until the CHANGED-P result
is NIL.
An implementation must save optimizer definitions created by
DEFINE-OPTIMIZER in case OPTIMIZE-EXPRESSION is attempted, but is
not actually required to call OPTIMIZE-EXPRESSION itself. Interpreters,
for example, may choose to just call the unoptimized form.
Using FLET and MACROLET shadow not only functions and their SETF methods,
but also their optimizers. No portable facility is provided for creating
locally defined optimizers.
The effect of defining optimizations for functions in the LISP package
is not defined. (In some implementations, this would clobber or conflict
with existing advice that may be of higher quality.)
The editor is advised that a non-binding style note such as the
following would also be appropriate:
In general, it is poor style for a programmer to define optimizers for
functions that he does not maintain. This is because the correct
implementation of an optimizer for a function usually depends on an
understanding of the internals of that function. As such, a function
definition and any optimizers should be maintained as a unit so that
they can changes in either can be synchronized as appropriate with the
other.
The effect of using DEFINE-OPTIMIZER on a function declared to be
INLINE is ``unspecified but harmless'' (per new Error Terminology).
That is, since both operations (optimization and inlining) are intended
to be semantics-preserving, no functional difference should be observed.
However, in some implementations the presence of an optimizer may thwart
the ability to inline, or vice versa. Writers of portable code are
encouraged to use either DEFINE-OPTIMIZER or (PROCLAIM '(INLINE ...))
but not both.
Example:
;; These examples are taken literally from the Macsyma sources,
;; modified only to change DEFOPT to DEFINE-OPTIMIZER. The comments
;; were specially written for the X3J13 audience.
;; M+ is adds a Macsyma expression to another Macsyma expression.
;; The Macsyma internal representation for the sum of X and Y is
;; ((MPLUS) X Y). A all the real work is done by SIMPLIFY, which
;; reduces the expression as needed necessary. However, SIMPLIFY
;; is very complicated, and considerable speed can be gained by
;; entering it at specific known places.
(DEFUN M+ (&REST TERMS)
(PROTECT-&REST-VARIABLE TERMS)
(SIMPLIFY `((MPLUS) ,@TERMS)))
(DEFINE-OPTIMIZER M+ (&REST TERMS)
(COND ((= (LENGTH TERMS) 2) `(ADD2* ,@TERMS))
(T `(ADDN (LIST ,@TERMS) NIL))))
;; M- negates a Macsyma expression, or substracts two Macsyma
;; expressions. Once you figure out which of the two operations is
;; to be done, the problem is similar to that of M+ above. However,
;; often the decision can be made at compile time. In this case,
;; INLINE functions would have worked ok, except that not all
;; implementations do inlining, and even those that do may fail to
;; recognize that EXP2 being NIL means that a test can be eliminated
;; or dead code can be eliminated. Using optimizers is far more
;; likely to be useful in practice.
(DEFUN M- (EXP1 &OPTIONAL (EXP2 NIL EXP2P))
(IF (NOT EXP2P)
(M--INTERNAL-NEGATE EXP1)
(M--INTERNAL-SUBTRACT EXP1 EXP2)))
(DEFINE-OPTIMIZER M- (EXP1 &OPTIONAL (EXP2 NIL EXP2P))
(IF (NOT EXP2P)
`(M--INTERNAL-NEGATE ,EXP1)
`(M--INTERNAL-SUBTRACT ,EXP1 ,EXP2)))
Rationale:
Many large portable applications expect such a facility on an
implementation-specific basis. Others would use one if available.
Even if implementations don't use the provided optimizers primitively,
user macros and code-walkers can invoke them, so the facility wouldn't
be completely useless even in those implementations.
Current Practice:
Symbolics Genera provides an optimizer facility which is more elaborate
but not fundamentally incompatible with this facility.
Many (if not most) serious implementations provide a similar facility.
For example, Lucid provides "compiler macros" which serve the same
purpose.
Cost to Implementors:
Since the implementation is not required to use this facility, the
cost of providing the proposed support is very small.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Portable code would be slower than necessary in some situations.
Benefits:
Some existing non-portable code could become portable.
Aesthetics:
Providing a separate optimizer definition from a main function definition
makes a possibility that the optimizer and main function could drift out
of synch. However, most places where this gets used in the first place
are places where speed is of paramount importance and the programmer is
willing to invest effort in maintaining things correctly and to accept the
risk of lossage if s/he fails.
This is a fairly clean and simple extension which adds significant
power to the compiler.
Discussion:
Pitman strongly supports this proposal, the design of which is modeled
directly after that which has been used in Macsyma for many years.
Information about argument type can come from two different sources:
THE and declarations (via PROCLAIM or DECLARE). The former information
is portably accessible, the latter is not. While a separate proposal
(SYNTACTIC-ENVIRONMENT-ACCESS) for allowing program access to type
declarations would be make this facility more useful, it is still
quite useful without it, as the examples from Macsyma illustrate.
Some implementations provide a way to provide more than one optimizer
for the same function. A multiple optimizer facility can be written
in terms of this simpler facility and vice versa, so the simpler of
the two facilities is proposed here.
Some people have suggested that they would like to see a pattern
matching facility integrated into this facility. The design of a
facility that would satisfy everyone would take a lot of time and
effort. At this point, there is no chance that the design of such a
facility would occur in time for acceptance into the standard.
The choice is this or nothing. Pitman thinks the language is much
better off with some form of optimization support than none.
Loosemore says:
Although I don't really think this is an essential feature to include
in the standard, I don't have any strong objection to adding it. If
people think it's a good idea to provide a standard interface for this
kind of thing, this is a good proposal for doing it -- it's fairly
simple, doesn't introduce any radically new ideas, and is general
enough to allow alternate interfaces (such as the pattern matcher) to
be layered on top of it.
Barrett says:
I think you may have gotten the sense of Cris' INLINE comment wrong.
I believe what he was suggesting is that NOTINLINE declarations should
inhibit optimizers, a position I agree with. I also think it would be
better to specify the behavior when both an optimizer and an inline
are present, rather than leaving it 'unspecified but harmless'. I'd
suggest that optimizers have precedence. The rational is that this
allows an optimizer to look for special patterns in the arguments, and
to defer to the inline if it doesn't find them. Of course, there's
the problem that the compiler might then ignore the inline.
∂13-Mar-89 1536 X3J13-mailer issue DEFINING-MACROS-NON-TOP-LEVEL, version 8
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:36:01 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA09314; Mon, 13 Mar 89 16:33:46 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02565; Mon, 13 Mar 89 16:33:44 -0700
Date: Mon, 13 Mar 89 16:33:44 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903132333.AA02565@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue DEFINING-MACROS-NON-TOP-LEVEL, version 8
Forum: Compiler
Issue: DEFINING-MACROS-NON-TOP-LEVEL
References: CLtL p. 66-70, 143
Issue EVAL-WHEN-NON-TOP-LEVEL
Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Issue COMPILER-LET-CONFUSION
Category: CLARIFICATION, ENHANCEMENT
Edit History: 6-May-88, V1 by Sandra Loosemore
9-Jun-88, V2 by Sandra Loosemore
12-Sep-88, V3 by Sandra Loosemore (fix garbled section 4)
21-Sep-88, V4 by Sandra Loosemore (clarify section 5)
16-Dec-88, V5 by Sandra Loosemore (major restructuring)
31-Dec-88, V6 by Sandra Loosemore (wording clarifications)
07-Jan-89, V7 by Sandra Loosemore (add example)
09-Mar-89, V8 by Sandra Loosemore (more restructuring)
Status: Ready for release
Problem Description:
CLtL leaves the interpretation of defining forms such as DEFMACRO and
DEFVAR that appear in other than top-level locations unclear.
On page 66, it is stated: "It is not illegal to use these forms at
other than top level, but whether it is meaningful to do so depends on
context. Compilers, for example, may not recognize these forms
properly in other than top-level contexts". At least one implementation
has interpreted this to mean that it is permissible to simply refuse
to compile defining macros that do not appear at top-level.
Proposal DEFINING-MACROS-NON-TOP-LEVEL:ALLOW:
(1) Remove the language from p. 66 of CLtL quoted above. Clarify that
while defining macros normally appear at top level, it is meaningful
to place them in non-top-level contexts and that the compiler must
handle them properly in all situations. However, the compile-time side
effects described in issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
only take place when the defining macros appear at top-level.
(2) Remove the language on p. 145 of CLtL, which states that macro
functions are always defined in the null lexical environment. Clarify
that all defining macros which create functional objects (including
DEFMACRO, DEFTYPE, DEFINE-SETF-METHOD, and the complex form of
DEFSETF, as well as DEFUN) must ensure that those functions are
defined in the lexical environment in which the defining form is
evaluated.
(3) Specify that top-level forms in a file being compiled are
guaranteed to be processed sequentially. The order in which
non-top-level subforms of a top-level form are processed by the
compiler is explicitly left unspecified.
Rationale:
This proposal makes the rules for when defining macros cause
compile-time side effects to be exactly the same as the rules for when
(EVAL-WHEN (COMPILE) ...) causes compile-time evaluation. This
provides a simple implementation technique.
Item (3) serves two purposes. First, it guarantees users that
compile-time side-effects from top-level EVAL-WHEN forms or defining
macros will happen in the correct order; programmers can depend upon
the compile-time side-effects of a top-level form being visible during
the compilation of subsequent forms. Second, it allows compilers to
perform certain kinds of source-to-source transformations that change
the order of subforms.
For instance, the following example from CLtL
(let ((old-count *access-count*))
(unwind-protect
(progn
(incf *access-count*)
(perform-access))
(setq *access-count* old-count)))
is entirely equivalent to:
(let ((old-count *access-count*))
(let ((thunk #'(lambda () (setq *access-count* old-count))))
(unwind-protect
(progn
(incf *access-count*)
(perform-access))
(funcall thunk))))
(This is a real example from the A-Lisp compiler, which implements
UNWIND-PROTECT by having it push a "thunk" to perform the cleanup
actions onto the catch stack before executing the protected form.)
Current Practice:
Most implementations do allow defining macros in non-top-level places.
However, the rules for when they cause compile-time side-effects are
not always the same as those for EVAL-WHEN. This is the case in
Lucid Common Lisp, for example.
Cost to implementors:
Implementations that currently don't compile defining macros correctly
when they appear at non-top-level will have to be changed.
Cost to users:
None. This is a compatible extension.
Benefits:
The notion of defining macros as being somehow special when they
appear at top-level is removed, since their behavior can be explained
using EVAL-WHEN as a primitive. Allowing defining macros to appear
anywhere instead of restricting them to certain positions results in a
cleaner language design.
Discussion:
This proposal is consistent with the behavior specified in proposal
EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL. In particular, if the compile
time side-effects for defining macros specified in proposal
COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY are implemented using
EVAL-WHEN, the "right" compiler behavior for defining macros at
non-top-level will happen automatically.
∂13-Mar-89 1545 X3J13-mailer issue EVAL-WHEN-NON-TOP-LEVEL, version 6
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:45:11 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA09664; Mon, 13 Mar 89 16:42:59 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02574; Mon, 13 Mar 89 16:42:54 -0700
Date: Mon, 13 Mar 89 16:42:54 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903132342.AA02574@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue EVAL-WHEN-NON-TOP-LEVEL, version 6
This issue has been giving us a lot of trouble for a long time. A few
people on the cl-compiler mailing list have expressed discontent with
the proposals included here, but the dissenters haven't been able to
come up with an acceptable alternative proposal that they can all agree
on.
Issue: EVAL-WHEN-NON-TOP-LEVEL
Forum: Compiler
References: EVAL-WHEN (CLtL pp69-70),
Issue DEFINING-MACROS-NON-TOP-LEVEL
Issue COMPILED-FUNCTION-REQUIREMENTS
Issue IN-PACKAGE-FUNCTIONALITY
Issue LOCALLY-TOP-LEVEL
Category: CLARIFICATION/CHANGE
Edit History: 06-May-88, Version 1 by Sandra Loosemore
16-Dec-88, Version 2 by Loosemore (alternate direction)
30-Dec-88, Version 3 by Loosemore (minor wording changes)
07-Jan-89, Version 4 by Loosemore (update discussion)
09-Feb-89, Version 5 by Pitman and Moon (some major changes)
09-Mar-89, Version 6 by Loosemore (clean up wording)
Status: Ready for release
Problem Description:
The current description of how the compiler should handle EVAL-WHEN
only makes sense when it appears as a top-level form in the file being
compiled. Is it legitimate for EVAL-WHEN to appear in non-top-level
locations? Even if it is legitimate, what does it mean?
Another issue, referred to here as ``the EVAL-WHEN shadowing problem,''
is that some people have complained that shadowing the symbols EVAL,
COMPILE, or LOAD means that you have to also either shadow EVAL-WHEN
and define it to recognize the new symbol, or else you must resign
yourself to writing (EVAL-WHEN (... LISP:EVAL ...) ...),etc. all over.
While the goal here is not to solve this problem, it might be possible
to solve both problems at once.
There are two proposals presented here, GENERALIZE-EVAL and
GENERALIZE-EVAL-NEW-KEYWORDS.
Background/Analysis:
The proposal which follows was constructed with the following goals
in mind:
1. The lexical and dynamic environment for the EVAL-WHEN body should
be the same for each situation. That is, the body should ``mean
the same thing'' regardless of which situation is being processed.
2. The evaluation context for EVAL-WHEN should be the current
lexical environment.
3. At execution time, EVAL-WHEN should always return the result of
its last form if execution of the body occurred, or NIL if the
body was not executed.
4. If a top-level EVAL-WHEN has a LOAD keyword, its body should
inherit top-level-ness during normal processing. This permits the
use of (EVAL-WHEN (EVAL COMPILE LOAD) ...) at top-level to mean
simply "Do whatever would normally be done for this body, but
also do something at compile time." This, in turn, will later be
the key to allowing defining forms to be usefully described in
terms of EVAL-WHEN.
5. Non-top-level expressions should have no effect until they are
executed. This is the key to making sure that any necessary
environment is present. Since the COMPILE keyword forces effects
to occur earlier than execution time, it follows from this that
any correct solution must not allow the COMPILE keyword to have
an effect at other than top-level.
To accomplish these goals, we formulated the following model:
The purpose of EVAL-WHEN is to accomodate the fact that some of the
semantic processing of an expression may usefully be partitioned
between compile time and run time in some circumstances.
(EVAL-WHEN (EVAL) <code>)
describes a general technique for accomplishing some particular goal
at normal program execution time. However, the pair of expressions
(EVAL-WHEN (COMPILE) <code-A>)
(EVAL-WHEN (LOAD) <code-B>)
can be used to describe an alternate technique for implementing part
of the effect (A) at compile-time, and part of the effect (B) at
load-time.
Proposal (EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL):
Replace the description of EVAL-WHEN with the following:
EVAL-WHEN ({situation}*) {form}* [Special Form]
The body of an EVAL-WHEN form is processed as an implicit PROGN, but
only in the situations listed. Each SITUATION must be a symbol,
either COMPILE, LOAD, or EVAL.
The use of COMPILE and LOAD controls whether and when processing
occurs for top-level forms. The use of EVAL controls whether
processing occurs for non-top-level forms.
The EVAL-WHEN construct may be more precisely understood in terms of
a model of how the file compiler, COMPILE-FILE, processes forms in a
file to be compiled.
Successive forms are read from the file by the file compiler using
READ. These top-level forms are normally processed in what we call
`not-compile-time' mode. There is one other mode, called
`compile-time-too' mode, which can come into play for top-level
forms. The EVAL-WHEN special form is used to annotate a program
in a way that allows the program doing the processing to select
the appropriate mode.
Processing of top-level forms in the file compiler works as follows:
* If the form is a macro call, it is expanded and the result is
processed as a top-level form in the same processing mode
(compile-time-too or not-compile-time).
* If the form is a PROGN form, each of its body forms is
sequentially processed as top-level forms in the same processing
mode.
* If the form is a COMPILER-LET, MACROLET, or SYMBOL-MACROLET,
the file compiler makes the appropriate bindings and recursively
processes the body forms as an implicit top-level PROGN with those
bindings in effect, in the same processing mode.
* If the form is an EVAL-WHEN form, it is handled according to
the following table:
COMPILE LOAD EVAL compile-time-too Action
Yes Yes -- -- Process body in compile-time-too mode
No Yes Yes Yes Process body in compile-time-too mode
No Yes Yes No Process body in not-compile-time mode
No Yes No -- Process body in not-compile-time mode
Yes No -- -- Evaluate body
No No Yes Yes Evaluate body
No No Yes No do nothing
No No No -- do nothing
"Process body" means to process the body as an implicit top-level
PROGN. "Evaluate body" means to evaluate the body forms as in
implicit PROGN in the dynamic execution context of the compiler and
in the lexical environment in which the EVAL-WHEN appears.
* Otherwise, the form is a top-level form that is not one of the
special cases. If in compile-time-too mode, the compiler first
evaluates the form and then performs normal compiler processing
on it. If in not-compile-time mode, only normal compiler
processing is performed. [The nature of this processing is
defined more precisely in issue COMPILED-FUNCTION-REQUIREMENTS.]
Any subforms are treated as non-top-level forms.
For an EVAL-WHEN form that is not a top-level form in the file compiler
(that is, one of: in the interpreter; in COMPILE; or in the file
compiler but not at top-level), if the EVAL situation is specified,
its body is treated as an implicit PROGN. Otherwise, the EVAL-WHEN
form returns NIL.
Clarifications/Consequences:
The following effects are logical consequences of the above proposal:
* It is never the case that the execution of a single EVAL-WHEN
expression will execute the body code more than once.
* The keyword `EVAL' is a misnomer because execution of
the body need not be done by EVAL. In compiled code, such as
(DEFUN FOO () (EVAL-WHEN (EVAL) (PRINT 'FOO)))
the call to PRINT should be compiled.
* Macros intended for use in top-level forms should arrange for all
side-effects to be done by the forms in the macro expansion.
The macro-expander itself should not do the side-effects.
Wrong: (defmacro foo ()
(really-foo)
`(really-foo))
Right: (defmacro foo ()
`(eval-when (compile eval load) (really-foo)))
Adherence to this convention will mean that such macros will behave
intuitively when placed in non-top-level positions.
* Placing a variable binding around an EVAL-WHEN reliably captures the
binding because the `compile-time-too' mode cannot occur (because
introducing a variable binding would mean we were not at top level).
For example,
(LET ((X 3))
(EVAL-WHEN (EVAL LOAD COMPILE) (PRINT X)))
will print 3 at execution [load] time, and will not print anything at
compile time. This is important so that expansions of DEFUN and
DEFMACRO can be done in terms of EVAL-WHEN and can correctly capture
the lexical environment.
(DEFUN BAR (X) (DEFUN FOO () (+ X 3)))
might expand into
(DEFUN BAR (X)
(PROGN (EVAL-WHEN (COMPILE)
(COMPILER::NOTICE-FUNCTION-DEFINITION 'FOO '(X)))
(EVAL-WHEN (EVAL LOAD)
(SETF (SYMBOL-FUNCTION 'FOO) #'(LAMBDA () (+ X 3))))))
which would be treated the same as
(DEFUN BAR (X)
(SETF (SYMBOL-FUNCTION 'FOO) #'(LAMBDA () (+ X 3))))
by the above rules.
Test Cases:
;; #1: The EVAL-WHEN in this case is not at top-level, so only the EVAL
;; keyword is considered. At compile time, this has no effect.
;; At load time (if the LET is at top level), or at execution time
;; (if the LET is embedded in some other form which does not execute
;; until later) this sets (SYMBOL-FUNCTION 'FOO1) to a function which
;; returns 1.
(LET ((X 1))
(EVAL-WHEN (EVAL LOAD COMPILE)
(SETF (SYMBOL-FUNCTION 'FOO1) #'(LAMBDA () X))))
;; #2: If this expression occurs at the top-level of a file to be compiled,
;; it has BOTH a compile time AND a load-time effect of setting
;; (SYMBOL-FUNCTION 'FOO2) to a function which returns 2.
(EVAL-WHEN (EVAL LOAD COMPILE)
(LET ((X 2))
(EVAL-WHEN (EVAL LOAD COMPILE)
(SETF (SYMBOL-FUNCTION 'FOO2) #'(LAMBDA () X)))))
;; #3: If this expression occurs at the top-level of a file to be compiled,
;; it has BOTH a compile time AND a load-time effect of setting the
;; function cell of FOO3 to a function which returns 3.
(EVAL-WHEN (EVAL LOAD COMPILE)
(SETF (SYMBOL-FUNCTION 'FOO3) #'(LAMBDA () 3)))
;; #4: This always does nothing. It simply returns NIL.
(EVAL-WHEN (COMPILE)
(EVAL-WHEN (COMPILE)
(PRINT 'FOO4)))
;; #5: If this form occurs at top-level of a file to be compiled, FOO5 is
;; printed at compile time. If this form occurs in a non-top-level
;; position, nothing is printed at compile time. Regardless of context,
;; nothing is ever printed at load time or execution time.
(EVAL-WHEN (COMPILE)
(EVAL-WHEN (EVAL)
(PRINT 'FOO5)))
;; #6: If this form occurs at top-level of a file to be compiled, FOO6 is
;; printed at compile time. If this form occurs in a non-top-level
;; position, nothing is printed at compile time. Regardless of context,
;; nothing is ever printed at load time or execution time.
(EVAL-WHEN (EVAL LOAD)
(EVAL-WHEN (COMPILE)
(PRINT 'FOO6)))
Rationale:
This is compatible with any guarantees made by CLtL, and extends the
behavior usefully to non-top-level situations.
This gives a useful meaning to EVAL-WHEN that supports useful and
predictable behavior if defining macros are used in a non-top-level
situation.
Proposal (EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL-NEW-KEYWORDS):
As in GENERALIZE-EVAL, but rename the EVAL keyword to :EXECUTE,
the COMPILE keyword to :COMPILE-TOPLEVEL, and LOAD keyword to
:LOAD-TOPLEVEL.
Deprecate the use of keywords EVAL, COMPILE, and LOAD to EVAL-WHEN.
For compatibility, they are supported in EVAL-WHEN
at top-level, but their meaning is not defined elsewhere.
Rationale:
The fact that the situation keywords chosen are not the same as
those now used means that the change can be added in a way that
is truly upward compatible (not only with CLtL but with existing
practice in implementations which have chosen to extend or `clarify'
the definition given in CLtL) since the meaning of EVAL, COMPILE,
and LOAD in non-top-level situations (which was never spelled
out in CLtL) can legitimately differ from the meaning of these
new keywords.
Using other names and/or the keyword package for the names of
situations solves the EVAL-WHEN shadowing problem.
The name `execute' does not promote the confusion that the body of an
EVAL-WHEN must be executed only in the evaluator. It also does not
promote the confusion that the body of an EVAL-WHEN, regardless of when
executed, must run interpreted.
The names `compile-toplevel' and `load-toplevel' emphasize the fact
that these cases are not interesting in non-top-level positions.
Current Practice:
In Symbolics Genera, the interpreter permits EVAL-WHEN in non-top-level
positions in a way that is compatible with this proposal but both the
COMPILE and COMPILE-FILE functions complain about EVAL-WHEN in a
non-top-level position.
Both Lucid Common Lisp and Kyoto Common Lisp already interpret the
EVAL keyword to mean "execute" in non-top-level situations. Both of
these implementations also make (EVAL-WHEN (LOAD) ...) suppress
compile-time "magic" from defining macros such as DEFMACRO.
IIM describes its EVAL-WHEN as:
(defmacro eval-when (situations &body body &environment env)
(if (not (compiler-environment-p env))
(when (member 'eval situations) `(progn ,@body))
(progn
(when (member 'compile situations)
(if (compiler-at-top-level-p env)
(mapc #'eval body)
(warn "Top-level form encountered at non-top-level.")))
(when (member 'load situations) `(progn ,@body)))))
Note that the interpretation of the EVAL situation and the nesting
behavior is different.
Cost to Implementors:
The actual change to EVAL-WHEN in both cases is probably fairly
localized and straightforward to make in most or all implementations.
The second-order costs of proposal GENERALIZE-EVAL will vary depending
on whether existing implementations have extended the definition of
EVAL-WHEN in incompatible ways. If an implementation has made such
extensions, there may be user and system code which depends on them
and the cost of converting that code may be non-trivial. There is
presumably also documentation impact.
Proposal GENERALIZE-EVAL-NEW-KEYWORDS avoids most or all of the
second-order costs of proposal GENERALIZE-EVAL.
The compiler processing for top-level forms might be implemented
something like:
;;; Forms read by the file compiler are passed to PROCESS-TOP-LEVEL-FORM
;;; with a env compile-time-too both NIL.
(defun process-top-level-form (form env compile-time-too)
(setq form (macroexpand form env))
(cond ((not (consp form))
nil)
((eq (car form) 'progn)
(dolist (f (cdr form))
(process-top-level-form f env compile-time-too)))
((eq (car form) 'compiler-let)
(process-compiler-let form env compile-time-too))
((eq (car form) 'macrolet)
(process-macrolet form env compile-time-too))
((eq (car form) 'symbol-macrolet)
(process-symbol-macrolet form env compile-time-too))
((eq (car form) 'eval-when)
(process-eval-when form env compile-time-too))
(t
(if compile-time-too
(internal-eval form env))
(compile-form form env))
))
(defun process-eval-when (form env compile-time-too)
(let* ((situations (cadr form))
(body (cddr form))
(compile-p (member 'compile situations))
(load-p (member 'load situations))
(eval-p (member 'eval situations)))
(cond ((or (and compile-p load-p)
(and eval-p load-p compile-time-too))
(process-top-level-form `(progn ,@body) env t))
(load-p
(process-top-level-form `(progn ,@body) env nil))
((or compile-p
(and eval-p compile-time-too))
(dolist (f body)
(internal-eval f env)))
(t
nil))))
;;; PROCESS-COMPILER-LET, PROCESS-MACROLET, and PROCESS-SYMBOL-MACROLET
;;; do the obvious things.
;;; INTERNAL-EVAL evaluates "form" in lexical environment "env".
Cost to Users:
Technically, none. Either proposal is technically upward compatible
with CLtL.
Proposal GENERALIZE-EVAL might force some extended implementations to
change incompatibly. As such, some users who depend on
implementation-dependent extensions might have to adjust their code
somewhat to deal with those changes.
Proposal GENERALIZE-EVAL-NEW-KEYWORDS does not force implementations
to change incompatibly, so has no forced impact on users.
Cost of Non-Adoption:
EVAL-WHEN is a mess. Using it as the low-level substrate into which
defining macros should expand, and guaranteeing any predictable effects
of those macros in non-top-level situations is currently difficult and
would continue to be so in the absence of some resolution on this issue.
Benefits:
The costs of non-adoption would be avoided: it would be possible to
use EVAL-WHEN in many situations where it cannot currently be used
reliably.
The portability of many existing tools which use EVAL-WHEN internally
in macros will be enhanced.
Aesthetics:
This generalization of the meaning makes the purpose and uses of
EVAL-WHEN less mysterious. In that sense, aesthetics are simplified
somewhat.
Discussion:
The cleanup issue LOCALLY-TOP-LEVEL would make LOCALLY also "pass
through" top-level-ness to its body. The reason why that is not
addressed in this issue is that it involves making LOCALLY a special
form.
Pitman and Moon don't care whether we say `top level,' `top-level,' or
`toplevel.' The spelling choices in this writeup are arbitrary. If
necessary, the proposal GENERALIZE-EVAL-NEW-KEYWORDS could be amended
to propose :COMPILE-TOP-LEVEL, etc.
Pitman, Moon, and Bob Laddaga (a Symbolics Cloe implementor) support
both of these proposals. Pitman and Laddaga have a preference for
GENERALIZE-EVAL-NEW-KEYWORDS. Moon is neutral about which should be
preferred.
Sandra Loosemore says:
I still feel somewhat uncomfortable with the definition of EVAL-WHEN
presented here, mostly because its nesting behavior is so unintuitive
(as in test case number 6). We have also had a hard time in deciding
what the term "top-level" really means; the definition presented here
is rather arbitrary. However, since we have run out of time in which
to come up with acceptable alternatives, I'm willing to go along with
proposal GENERALIZE-EVAL. It is compatible with the description in
CLtL but presented in a more coherent way, and I think it is an
improvement. On the other hand, I don't really like the idea of
changing the names of the keywords; if we are going to make an
incompatible change, the right thing to do would be to throw out
EVAL-WHEN entirely and start from scratch.
∂13-Mar-89 1601 X3J13-mailer **DRAFT** issue MACRO-ENVIRONMENT-EXTENT, version 3
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:57:19 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA10215; Mon, 13 Mar 89 16:55:08 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02585; Mon, 13 Mar 89 16:55:05 -0700
Date: Mon, 13 Mar 89 16:55:05 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903132355.AA02585@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: **DRAFT** issue MACRO-ENVIRONMENT-EXTENT, version 3
This issue is still under discussion. There are three proposals
presented formally and two more mentioned informally in the discussion
section, but it appears that the decision is really between proposal
DYNAMIC and everything else.
Forum: Compiler
Issue: MACRO-ENVIRONMENT-EXTENT
References: CLtL p. 145-146
Issue COMPILER-LET-CONFUSION
Issue MACRO-CACHING
Issue EVAL-WHEN-NON-TOP-LEVEL
Issue SYNTACTIC-ENVIRONMENT-ACCESS
CLOS Chapter 3 (89-003)
Category: CLARIFICATION,CHANGE
Edit History: V1, 10 Jan 1989, Sandra Loosemore
V2, 09 Mar 1989, Sandra Loosemore
V3, 13 Mar 1989, Sandra Loosemore (last-minute discussion)
Status: **DRAFT**
Problem Description:
What is the extent of environment objects received as the &ENVIRONMENT
argument of a macro function?
CLtL says that &ENVIRONMENT is "useful primarily in the rare cases
where a macro definition must explicitly expand any macros in a
subform of the macro call before computing its own expansion". While
this suggests that macro environment objects are typically used within
the dynamic scope of the macro function, the use of the word
"primarily" (rather than "only" or "exclusively" or some similarly
strong language) suggests that there may be other legitimate uses for
environment objects. But, because CLtL is silent about what those
uses might be, many users and implementors are under the impression
that environment objects have only dynamic extent.
There are some situations where using environment objects as if they
had indefinite extent provides a very useful viewpoint from which to
solve a problem. Consider the following example:
(defmacro typed-var (var) var)
(defmacro local-type-declare (declarations &body forms &environment env)
`(macrolet ((typed-var (&whole w var)
(let ((type (assoc var ',declarations)))
(if type
`(the ,(cadr type) ,var)
(macroexpand w ',env)))))
,@forms))
(defun f (x y)
(local-type-declare ((x fixnum) (y float))
(+ (typed-var x) (typed-var y))))
Here, local macro TYPED-VAR is defined to look first in the innermost
lexical environment for information about the variable, and if there
isn't any then it recurses on the next outermost lexical environment.
The global definition of TYPED-VAR provides a terminal case to stop
the recursion.
There are other situations where the extent of macro environment
objects comes into play. For example, if we allow caching of macro
expansions (issue MACRO-CACHING), environments must have indefinite
extent. It is unclear whether CLOS would be affected by allowing
macro environments to have only dynamic extent. (The descriptions of
the CLOS defining macros in document 89-003 seem to imply that the
value of the &ENVIRONMENT argument appears in the expansion of the
macro, but there now seems to be sentiment that the model of how the
defining macros work that is presented there is broken.)
Proposal MACRO-ENVIRONMENT-EXTENT:INDEFINITE:
State that macro environment objects received with the &ENVIRONMENT
argument of a macro function or as the argument to a *MACROEXPAND-HOOK*
function have indefinite extent.
Note that implementations are not permitted to destructively modify
lexical information in environment objects once they have been passed
to a macro function. It is, however, permissible to add or remove
global definitions that are accessible through the environment.
Rationale:
This legitimizes the use of idioms which depend on macro environments
having indefinite extent.
Since data objects in Lisp otherwise have indefinite extent, it is
more consistent to give environment objects indefinite extent as
well.
Proposal MACRO-ENVIRONMENT-EXTENT:DYNAMIC:
State that macro environment objects received with the &ENVIRONMENT
argument of a macro function or with a *MACROEXPAND-HOOK* function
have only dynamic extent; the consequences are undefined if they are
referred to outside the dynamic extent of that macro function or hook
function.
Rationale:
This allows implementations to use somewhat more efficient techniques
for representing environment objects. For example, the storage could
be stack-allocated, or environments could be bashed destructively
instead of always being freshly heap-allocated.
Proposal MACRO-ENVIRONMENT-EXTENT:DYNAMIC-WITH-COPIER:
State that macro environment objects received with the &ENVIRONMENT
argument of a macro function or with a *MACROEXPAND-HOOK* function
have only dynamic extent; the consequences are undefined if they are
referred to outside the dynamic extent of that macro function or hook
function.
Add a new function:
COPY-ENVIRONMENT environment [function]
This function returns an environment object that is semantically
equivalent to "environment" (which must be an object of the type
received with an &ENVIRONMENT argument to a macro or as an argument to
a *MACROEXPAND-HOOK* function), but which may safely be referred to
outside the dynamic extent of the macro function. This function is
permitted to return an object that is EQ to its argument if that
object may be safely used.
Rationale:
This allows implementations to use somewhat more efficient techniques
for representing environment objects. For example, the storage could
be stack-allocated, or environments could be bashed destructively
instead of always being freshly heap-allocated.
It also allows programmers to use idioms that rely on environment
objects having indefinite extent.
Current Practice:
Macro environments appear to have indefinite extent in Lucid Common
Lisp, Kyoto Common Lisp, CMU Common Lisp (at least in the
interpreter), Utah Common Lisp, and A-Lisp. A-Lisp internally uses
the kind of idiom shown in the example above to implement FLET,
LABELS, and FUNCTION as macros.
Macro environments are stack-allocated in Symbolics Genera, and hence
have dynamic extent.
Macro environments also have dynamic extent on the TI Explorer,
because the compiler uses special variables are used to keep track of
lexical definitions.
Cost to implementors:
For proposal INDEFINITE, some implementations would need to change. A
simple implementation of macro environments that would fit the
requirements of this proposal is to represent them as lists, pushing
information for inner contours onto the front of the list as the
contour is entered and popping the list when the contour is exited.
For proposal DYNAMIC, there is no associated implementation cost.
For proposal DYNAMIC-WITH-COPIER, the implementation cost is unknown
but probably fairly small in most implementations.
Cost to users:
For proposal INDEFINITE, there is no associated cost to users.
For proposal DYNAMIC, users would not be able to portably use a
simple and elegant approach to solving certain kinds of problems.
For proposal DYNAMIC-WITH-COPIER, users would have to remember to make
a copy of an environment object in some situations.
Benefits:
It is made clear whether treating environment objects as if they had
indefinite extent is portable usage.
Discussion:
Proposal SYNTACTIC-ENVIRONMENT-ACCESS:ADD-FUNCTIONAL-INTERFACE
includes adding a function called AUGMENT-ENVIRONMENT which could also
be used to create a copy of an environment. However, it returns an
object with the same extent as its argument, and therefore can not
replace the function COPY-ENVIRONMENT under proposal
DYNAMIC-WITH-COPIER.
We have also considered a couple of other alternatives on this
issue.
One alternative would be to give "remote" environments created by
COMPILE-FILE the extent of that call to COMPILE-FILE, while "local"
environments (the null lexical environment and environments created by
COMPILE and EVAL) would have indefinite extent.
Another alternative would be to say that environments created by
COMPILE-FILE, COMPILE, or EVAL have a dynamic extent that includes the
time when any other macro calls appearing lexically within the
expansion returned by the macro function are expanded. This is
similar to the extent of the special bindings made by COMPILER-LET.
Both of these proposals could be combined with adding a copier
function to deal with those implementations where environments are
stack-allocated. They would both solve the extent problem for the
example given in the problem description section, but not the general
problem of macro caching. In conjunction with the proposals for issue
SYNTACTIC-ENVIRONMENT-ACCESS, they would both require some
modifications to implementations that currently give macro
environments dynamic extent.
Loosemore supports proposal MACRO-ENVIRONMENT-EXTENT:INDEFINITE.
Moon says:
My opinion is that anything in CLOS that seems to depend on indefinite
extent for macro environments is broken and needs to be fixed. It's not
broken because of the environment extent, but for other reasons.
Thus I believe in dynamic extent for environments.
Neil Goldman says:
In my code walker I have a pretty ugly way of dealing with MACROLET
that would have been trivial if I could have counted on the
ENVIRONMENT having indefinite extent. There may be some cleaner way
than what I did, but I just looked at PCL's code walker, and it also
is much more complex than would be necessary if environments had
indefinite extent.
∂13-Mar-89 1610 X3J13-mailer **DRAFT** issue PROCLAIM-ETC-IN-COMPILE-FILE (version 4)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 16:10:26 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA10862; Mon, 13 Mar 89 17:08:13 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02608; Mon, 13 Mar 89 17:08:10 -0700
Date: Mon, 13 Mar 89 17:08:10 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903140008.AA02608@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: **DRAFT** issue PROCLAIM-ETC-IN-COMPILE-FILE (version 4)
This is a new writeup for an issue that was first brought up several
months ago. We haven't had time to review it thoroughly yet.
Issue: PROCLAIM-ETC-IN-COMPILE-FILE
References: CLtL p. 182 [package functions],
p. 156 [PROCLAIM], p. 439 [COMPILE-FILE];
Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
Issue IN-PACKAGE-FUNCTIONALITY
Issue EVAL-WHEN-NON-TOP-LEVEL
Issue DEFINING-MACROS-NON-TOP-LEVEL
Category: CLARIFICATION, CHANGE, ADDITION
Edit History: 15 Sep 88, V1 by David Gray
23 Sep 88, V2 by Sandra Loosemore (summarize discussion)
11 Mar 89, V3 by Sandra Loosemore (rewrite)
13 Mar 89, V4 by Sandra Loosemore (discussion)
Status: **DRAFT**
Problem Description:
Should the compiler treat top-level calls to PROCLAIM specially?
Page 182 of CLtL says that COMPILE-FILE needs to treat top-level calls
to the following package functions as though they were wrapped in an
(EVAL-WHEN (COMPILE LOAD EVAL) ...):
EXPORT IMPORT IN-PACKAGE MAKE-PACKAGE SHADOW
SHADOWING-IMPORT UNEXPORT UNUSE-PACKAGE USE-PACKAGE
CLtL is silent on whether top-level calls to PROCLAIM should also be
evaluated at compile-time, which presumably means they shouldn't be.
However, some implementations do evaluate PROCLAIM at compile-time.
In the model of how COMPILE-FILE works that is presented in issues
EVAL-WHEN-NON-TOP-LEVEL and DEFINING-MACROS-NON-TOP-LEVEL, the special
form EVAL-WHEN is the only thing that can cause compile-time evaluation
to occur. The compile-time side-effects of macros such as DEFMACRO
and DEFPACKAGE are explained by having them include EVAL-WHEN in their
expansions. Any functions that are treated specially, however, must
be included as special cases in the compiler.
Proposal IN-PACKAGE-FUNCTIONALITY:NEW-MACRO would remove the
requirement that the package functions be treated specially. Do we
wish to make an exception to the model for PROCLAIM?
Proposal PROCLAIM-ETC-IN-COMPILE-FILE:YES:
Require COMPILE-FILE to treat top-level calls to PROCLAIM as if they
were wrapped in an (EVAL-WHEN (COMPILE LOAD EVAL) ...).
Rationale:
Proclamations affect compilation semantics and should be made
available to the compiler.
Proposal PROCLAIM-ETC-IN-COMPILE-FILE:NO:
Clarify that calls to PROCLAIM should be treated the same as any
other function call. Users should wrap an explicit EVAL-WHEN around
top-level calls to PROCLAIM if they want them to affect compilation.
Rationale:
This makes the semantics of COMPILE-FILE more uniform and easier
to understand. In particular, if we remove the magic compile-time
behavior of the package functions, it seems silly to add another
exception for PROCLAIM.
Proposal PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO:
Add a new macro:
DEFPROCLAIM &rest decl-specs [Macro]
This macro PROCLAIMs the given <decl-specs>, which are not
evaluated. If a call to this macro appears at top-level in a file
being processed by the file compiler, the proclamations are also
made at compile-time. As with other defining macros, it is
unspecified whether or not the compile-time side-effects of a
DEFPROCLAIM persist after the file has been compiled.
Clarify that calls to PROCLAIM should be treated the same as any
other function call. Users should wrap an explicit EVAL-WHEN around
top-level calls to PROCLAIM if they want them to affect compilation,
or use the macro DEFPROCLAIM.
Rationale:
The macro makes the proclamations available to the compiler in such
a way that does not require any special exceptions to be made in
the model of how COMPILE-FILE works.
Current Practice:
The TI explorer apparently implements proposal YES, except that
(EVAL-WHEN (LOAD) (PROCLAIM '(OPTIMIZE ...))) doesn't do anything.
The Symbolics compiler has special top-level handling for PROCLAIM,
although the details are not clear.
Lisps developed at Utah (UCL, A-Lisp, PSL/PCLS) do not give PROCLAIM
any special compile-time handling.
Lucid does not evaluate calls to PROCLAIM at compile-time.
The IIM compiler has special top-level handling for PROCLAIM when
the argument is a constant. The information is recorded in the remote
environment.
Cost to implementors:
Since implementations are already required to have a mechanism for
compile-time handling of the package functions, it would probably
only require minor adjustments to add handling for PROCLAIM.
Cost to users:
For proposal YES, users would have no way to suppress compile-time
evaluation of a top-level call to PROCLAIM. Wrapping it in an
(EVAL-WHEN (EVAL LOAD)...) wouldn't work under the model of how
EVAL-WHEN works in proposal EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL.
Under any of these proposals, some users would probably have to
make minor changes to their code.
Benefits:
Users will know what to expect when they use PROCLAIM.
Costs of Non-Adoption:
Users will not know what to expect when they use PROCLAIM.
Aesthetics:
At least two people consider requiring magic behavior for certain
top-level function calls to be "semantically bletcherous". Removing
all special cases for functions that are implicitly evaluated at
compile-time would simplify the model of how COMPILE-FILE works.
Programs look cleaner if EVAL-WHEN is only needed for unusual cases
instead of being required for the normal cases.
Discussion:
The first version of this writeup also included REQUIRE with PROCLAIM,
but we have now voted to remove REQUIRE from the language entirely.
It also specified that OPTIMIZE proclamations should only have a local
effect within the file being compiled. This was removed for
consistency with other compile-time side-effects (such as those from
DEFMACRO), where their persistence is explicitly left unspecified.
Loosemore favors proposal NO, but wouldn't oppose proposal NEW-MACRO.
Kim Barrett says:
Proposal YES violates the general approach we've been taking of trying
to limit side-effects on the local environment during compilation.
Proposal NO makes PROCLAIM virtually worthless.
Proposal NEW-MACRO -- While this matches up with other stuff we've
been doing, I'm concerned about two things. First, I really dislike
the name DEFPROCLAIM. This thing isn't defining anything! It sounds
like something that modifies the behavior of PROCLAIM, not something
that actually makes a proclamation. Second, I'm concerned about the
cost to users. I think the statement that
"Under any of these proposals, some users would probably have to make
minor changes to their code."
is rather misleading for this case. There are a lot of PROCLAIMs out
there.
Loosemore replies:
....but all of those uses of PROCLAIM are already nonportable. No
matter what we do here, somebody is going to get burned.
Suggestions for better names for the macro are welcome.
∂13-Mar-89 1622 X3J13-mailer **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 16:22:04 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA11265; Mon, 13 Mar 89 17:19:53 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02631; Mon, 13 Mar 89 17:19:48 -0700
Date: Mon, 13 Mar 89 17:19:48 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903140019.AA02631@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
This issue is also still under discussion. This version of the writeup
is fairly new and hasn't been reviewed thoroughly yet.
Forum: Compiler
Issue: SYNTACTIC-ENVIRONMENT-ACCESS
References: CLtL Chapter 8: Macros,
Issue MACRO-FUNCTION-ENVIRONMENT,
Issue GET-SETF-METHOD-ENVIRONMENT,
Issue COMPILE-FILE-ENVIRONMENT
Related Issues: Issue FUNCTION-NAME,
Issue PROCLAIM-LEXICAL
Issue MACRO-ENVIRONMENT-EXTENT
Category: ADDITION
Edit history: Version 1, 2-Oct-88, Eric Benson
Version 2, 17-Feb-89, Kim A. Barrett
Version 3, 9-Mar-89, Kim A. Barrett (respond to comments)
Version 4, 12-Mar-89, Sandra Loosemore (more revisions)
Status: **DRAFT**
Problem description:
When macro forms are expanded, the expansion function is called with
two arguments: the form to be expanded, and the environment in which
the form was found. The environment argument is of limited utility.
The only use sanctioned currently is as an argument to MACROEXPAND or
MACROEXPAND-1 or passed directly as an argument to another macro
expansion function. Recent cleanup issues propose to allow it as an
argument to MACRO-FUNCTION and to GET-SETF-METHOD.
It is very difficult to write a code walker that can correctly handle
local macro and function definitions, due to insufficient access to
the information contained in environments and the inability to
augment environments with local definitions.
Some people believe that the CLOS meta-object protocol will require the
ability to distinguish between remote environments used for compiling
to a file, from local environments used for processing by EVAL or
COMPILE. (However, there is no requirement in chapters 1 & 2 of the
CLOS spec that things be done this way.)
There are three proposals; SMALL, MEDIUM, and LARGE.
Proposal (SYNTACTIC-ENVIRONMENT-ACCESS:SMALL):
The following functions provide information about syntactic
environment objects. In all of these functions the argument named ENV
is an environment of the sort received by the &ENVIRONMENT argument to
a macro or as the environment argument for EVALHOOK. Optional "env"
arguments default to NIL, which respresents the local null lexical
environment (containing only global definitions and proclamations
that are present in the runtime environment). All of these functions
should signal an error of type TYPE-ERROR if the value of an
environment argument is not a syntactic environment.
VARIABLE-KIND variable &optional env [Function]
VARIABLE is a symbol. This function returns one of the following
symbols, depending on the type of definition or binding which is
apparent in ENV.
NIL There is no apparent definition or binding for variable.
:SPECIAL VARIABLE refers to a special variable, either declared
or proclaimed.
:LEXICAL VARIABLE refers to a lexical variable.
:SYMBOL-MACRO VARIABLE refers to a SYMBOL-MACROLET binding.
:CONSTANT VARIABLE refers to a named constant, defined by
DEFCONSTANT.
[Note: If issue PROCLAIM-LEXICAL passes, then the :LEXICAL result
will also refer to variables proclaimed lexical.]
Example:
(DEFMACRO KIND-OF-VARIABLE (VAR &ENVIRONMENT ENV)
`',(VARIABLE-KIND VAR ENV))
(DEFVAR A)
(DEFUN TEST ()
(LET (B)
(LET (C)
(DECLARE (SPECIAL C))
(SYMBOL-MACROLET ((D ANYTHING))
(LIST (KIND-OF-VARIABLE A)
(KIND-OF-VARIABLE B)
(KIND-OF-VARIABLE C)
(KIND-OF-VARIABLE D)
(KIND-OF-VARIABLE E))))))
(TEST) -> (:SPECIAL :LEXICAL :SPECIAL :SYMBOL-MACRO NIL)
FUNCTION-KIND function &optional env [Function]
FUNCTION is a function name. This function returns two values,
depending on the type of function definition or function binding
which is apparent for FUNCTION in ENV.
NIL There is no apparent definition for FUNCTION.
:FUNCTION FUNCTION refers to a function.
:MACRO FUNCTION refers to a macro.
:SPECIAL-FORM FUNCTION refers to a special form.
The second value specifies whether the definition is local or
global. If local, the second value is true, and it is false when
the definition is global.
Some function names may refer to both a global macro and a global
special form. In such a case, the macro takes precedence, and
:MACRO is returned as the first value.
[Note: The use of "function name" rather than "symbol" as the
description of the function argument is intended to be compatible
with the various proposals to extend the syntax of function
specifiers. If no such change actually occurs then this would only
refer to symbols.]
Example:
(DEFMACRO KIND-OF-FUNCTION (FUNCTION-NAME &ENVIRONMENT ENV)
`',(FUNCTION-KIND FUNCTION-NAME ENV))
(DEFUN A ())
(DEFMACRO B ())
(DEFUN TEST ()
(FLET ((C ()))
(MACROLET ((D ()))
(MULTIPLE-VALUE-CALL #'LIST
(KIND-OF-FUNCTION A)
(KIND-OF-FUNCTION B)
(KIND-OF-FUNCTION QUOTE)
(KIND-OF-FUNCTION C)
(KIND-OF-FUNCTION D)
(KIND-OF-FUNCTION E)))))
(TEST) -> (:FUNCTION NIL
:MACRO NIL
:SPECIAL-FORM NIL
:FUNCTION T
:MACRO T
NIL NIL)
VARIABLE-TYPE variable &optional env [Function]
VARIABLE is a symbol. This function returns the type specifier
associated with the variable named by the symbol in the environment.
If no explicit association exists, either by PROCLAIM or DECLARE,
then the result is the type specifier T.
The result of this function may not include all the apparent TYPE
declarations for VARIABLE. In particular, an implementation is free
to ignore TYPE declarations, only returning TYPE information which
was added to ENV by a call to AUGMENT-ENVIRONMENT.
Example:
This example assumes that the implementation records type
information in the environment, rather than ignoring it.
(DEFMACRO VARTYPE (VAR &ENVIRONMENT ENV)
`',(VARIABLE-TYPE VAR ENV))
(DEFVAR A 1)
(PROCLAIM '(FIXNUM A))
(DEFUN TEST ()
(LET ((B (AREF "X" 0))
(C 3))
(DECLARE (STRING-CHAR B))
(LIST (VARTYPE A) (VARTYPE B) (VARTYPE C))))
(TEST) -> (FIXNUM STRING-CHAR NIL)
FUNCTION-FTYPE function &optional env [Function]
FUNCTION is a function name. This function returns the functional
type specifier associated with the function in the environment, or
the symbol FUNCTION if there is no functional type declaration or
proclamation associated with the function.
The result of this function may not include all the apparent FTYPE
declarations for FUNCTION. In particular, an implementation is free
to ignore FTYPE declarations, only returning FTYPE information which
was added to ENV by a call to AUGMENT-ENVIRONMENT.
Example:
This example assumes that the implementation records ftype
information in the environment, rather than ignoring it.
(DEFMACRO FUNTYPE (FUN &ENVIRONMENT ENV)
`',(FUNCTION-FTYPE FUN ENV))
(DEFUN A-FUNCTION (X)
(+ X 3))
(PROCLAIM '(FTYPE (FUNCTION (FIXNUM) FIXNUM) A-FUNCTION))
(DEFUN TEST ()
(FLET ((ANOTHER-FUNCTION (X)
(+ X 2)))
(DECLARE (FTYPE (FUNCTION (INTEGER) INTEGER) ANOTHER-FUNCTION))
(LIST (FUNTYPE A-FUNCTION) (FUNTYPE ANOTHER-FUNCTION))))
(TEST) -> ((FUNCTION (FIXNUM) FIXNUM) (FUNCTION (INTEGER) INTEGER))
AUGMENT-ENVIRONMENT env &KEY variable
symbol-macro
function
macro
declare [Function]
This function returns a copy of ENV, augmented with the information
provided by the keyword arguments. The arguments are supplied as
follows:
:VARIABLE A list of symbols which shall be visible as bound
variables in the new environment. Whether each
binding is to be interpreted as special or lexical
depends on SPECIAL declarations recorded in the
environment or provided in the :DECLARE argument list.
:SYMBOL-MACRO A list of symbol macro definitions, in the same format
as the CADR of a SYMBOL-MACROLET special form. The
new environment will have local symbol-macro bindings
of each symbol to the corresponding expansion, so that
MACROEXPAND will be able to expand them properly.
:FUNCTION A list of function names which shall be visible as local
function bindings in the new environment.
:MACRO A list of local macro definitions, in the same format
as the CADR of a MACROLET special form. The new
environment will have local macro bindings of each
name to the corresponding expander function, which
will be returned by MACRO-FUNCTION and used by
MACROEXPAND.
:DECLARE A list of decl-specs. The new environment will
contain information about SPECIAL, TYPE, and FTYPE
declarations appearing within the list.
An error is signalled if any of the symbols naming macros in the
:SYMBOL-MACRO alist are also included in the :VARIABLE list.
An error is signalled if any of the names specified as keys in the
:MACRO alist are also included in the :FUNCTION list. The consequences
of destructively modifying the list structure of any of the arguments
to this function are undefined.
The extent of the returned environment is the same as the extent of
the argument.
While an environment argument from EVALHOOK may be used as the
environment argument for this function, the reverse is not true. If
an attempt is made to use the result of AUGMENT-ENVIRONMENT as
the environment argument for EVALHOOK, the consequences are undefined.
The environment returned by AUGMENT-ENVIRONMENT may only be used for
syntactic analysis, ie. the functions specified by this proposal and
functions such as MACROEXPAND.
[If PROCLAIM-LEXICAL is adopted, LEXICAL declarations would also
be recognized.]
Rationale:
This proposal defines a minimal set of accessors and a constructor
for environments.
The symbol-macro and macrolet definitions and declarations passed
to AUGMENT-ENVIRONMENT are in the same form as those which would
normally be encountered by a code-walker. This makes it easier to
use. In particular, there is no need for users to write their own
code to destructure macro arguments.
Making TYPE and FTYPE information optional continues to allow
implementations the freedom to simply ignore all such declarations.
Proposal (SYNTACTIC-ENVIRONMENT-ACCESS:MEDIUM):
This is the same as proposal SMALL, but also includes:
There are two kinds of environments, local and remote. Local
environments are created by EVAL and COMPILE, and are used in
situations where the information in the environment pertains
to the immediate running Lisp environment. Remote environments
are used by processors such as COMPILE-FILE to model what the
Lisp environment will look like when the code being processed
is actually loaded.
If AUGMENT-ENVIRONMENT receives a remote environment as an argument,
then the new environment returned by this function will also be
remote, and the two will refer to the same model of the remote
environment.
ENVIRONMENT-REMOTE-P env [Function]
Returns true if ENV is a remote environment, false otherwise.
WITH-REMOTE-ENVIRONMENT var &body body [Macro]
Evaluates the BODY forms with VAR bound to a newly created remote
environment. The extent of the environment is the dynamic extent of
the WITH-REMOTE-ENVIRONMENT form.
This is the only specified mechanism by which a new remote
environment may be created.
Rationale:
The notion of local and remote environments may be useful for
developing the CLOS meta-object protocol. At some future time,
we may wish to tighten the specification of how compile-time
definitions of defining macros such as DEFMACRO or DEFCLASS are
achieved, by saying that the compile-time definitions must be made
only in the remote environment.
Proposal (SYNTACTIC-ENVIRONMENT-ACCESS:LARGE):
This is the same as proposal MEDIUM, but also includes:
ENVIRONMENT-PROPERTY env name property &optional default
This function and its SETF method allow the association of arbitrary
'global' properties with names within an environment. An
environment can be thought of as having a local property list
associated with any name, and this function provides access to that
property list.
A remote environment may be thought of as an extension of the local
environment. Thus, when this function is applied to a remote
environment and the property is not found, the global local environment
is then searched.
The association between names and property lists uses EQUAL to match
names. The search of the property list uses EQ to match properties.
If the property is not found, DEFAULT is returned.
Using SETF of ENVIRONMENT-PROPERTY affects all environments which
refer to the same environment model. In particular, if ENV is a
local environment then all local environments are affected, while if
ENV is a remote environment, then all environments refering to the
same remote environment model as the argument are affected.
[Note: The local property list of a name is not necessarily the
symbol-plist of the name, though that is a possible implementation
for names which are symbols.
Note: The use of EQUAL as the matching function for names is to
allow for proposed extensions to function names. If no such
extension occurs, then EQ could be used instead.]
Rationale:
This would provide a mechanism for making and accessing global
definitions in the remote environment.
Cost to Implementors:
Most implementations already record some of this information in some
form. Providing these functions should not be too difficult, but it
is a more than trivial amount of work.
Cost to Users:
This change is upward compatible with user code.
Current practice:
No implementation provides all of this interface currently. Portable
Common Loops defines a subset of this functionality for its code
walker and implements it on a number of diffent versions of Common
Lisp. IIM uses the functionality provided by ENVIRONMENT-REMOTE-P
and ENVIRONMENT-PROPERTY (under other names) to implement the
association between names and remote metaobjects (macro and type
definitions, CLOS remote metaobjects, &etc).
Discussion:
The first version of this proposal expressly did not deal with the
objects which are used as environments by EVALHOOK. This version is
extended to support them in the belief that such environments share a
lot of functionality with the syntactic environments needed by a
compiler. While the two types of environments may have very
different implementations, there are many operations which are
reasonable to perform on either type, including all of the accessor
functions described by this proposal.
AUGMENT-ENVIRONMENT currently requires signaling an error when
symbol-macro names match variable names in the same call. This could
be reduced to "should signal". By requiring the error signaling, this
proposal is compatable with Proposal SYMBOL-MACROLET-DECLARE:ALLOW,
which says
"... signals an error if a SPECIAL declaration names one of the symbols
being defined as a symbol-macrolet."
Maintaining compatability with the SYMBOL-MACROLET-DECLARE proposal
allows fairly trivial implementations of the SYMBOL-MACROLET
special-form in terms of the AUGMENT-ENVIRONMENT function.
An possible alternative syntax for WITH-REMOTE-ENVIRONMENT might be
WITH-REMOTE-ENVIRONMENT (var &key) &body body
Can anyone suggest candidates for keyword options? We could do this
even if we can't think of any immediately, leaving room for
implementation-specific extensions. One candidate option that some
implementations might want would be to specify a target machine for
the compilation.
Kim Barrett originally suggested that WITH-COMPILATION-UNIT should
provide the mechanism for creating new remote environments. However,
it has been suggested that WITH-COMPILATION-UNIT is intended to serve
a somewhat different purpose.
Sandra Loosemore says:
I support proposal SMALL but would vote against both of the larger
proposals. It's true that they provide functionality which *might* be
useful to implement CLOS, but there is nothing now in the standard
that *requires* this functionality to be added. In fact, the version
of issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS that was accepted at
the January meeting explicitly leaves unspecified the mechanism by
which defining macros make definitions available to the compiler. We
have very little practical experience with using environment objects
for this purpose and I think it would be premature to try to
standardize it at this point. In particular, since the meta-object
protocol is still undergoing what appear to be substantial changes,
let's wait until it settles down and then see what kind of compiler
hooks it needs, instead of possibly standardizing the wrong thing.
∂13-Mar-89 1627 X3J13-mailer issue WITH-COMPILATION-UNIT, version 3
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 16:27:44 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA11422; Mon, 13 Mar 89 17:25:34 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02634; Mon, 13 Mar 89 17:25:31 -0700
Date: Mon, 13 Mar 89 17:25:31 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903140025.AA02634@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: issue WITH-COMPILATION-UNIT, version 3
Forum: Compiler
Issue: WITH-COMPILATION-UNIT
References: COMPILE (p438), COMPILE-FILE (p439)
Category: ADDITION
Edit history: 29-Sep-88, Version 1 by Pitman
10-Mar-89, Version 2 by Pitman (merge comments)
13-Mar-89, Version 3 by Loosemore (update discussion)
Status: Ready for release
Problem Description:
Some actions done by the compiler (and particularly the file compiler)
are typically deferred until the "very end" of compilation. For example,
some compilers complain about "functions seen but not defined".
Unfortunately, since COMPILE-FILE is the largest unit of granularity,
and since systems often extend over more than one file, it often happens
that the compiler needlessly complains at the end of compiling one file
about the absence of functions defined in the next file.
Proposal (WITH-COMPILATION-UNIT:NEW-MACRO):
Add the following new macro:
WITH-COMPILATION-UNIT options &BODY forms [Macro]
Executes forms from left to right. Within the dynamic context
of this form, actions deferred by the compiler until "the end of
compilation" will be deferred until the end of the outermost call
to WITH-COMPILATION-UNIT. The result(s) are the same as that of
the last of the FORMS (or NIL if FORMS is null).
OPTIONS is a keyword/value list, where only the values are
evaluated. The set of keywords permitted may be extended by the
implementation, but the only keyword defined by this standard is:
:OVERRIDE boolean
The default is NIL. If nested dynamically only the outer call
to WITH-COMPILATION-UNIT has any effect unless BOOLEAN is T,
in which case warnings are deferred only to the end of the
innermost call.
It follows that the functions COMPILE and COMPILE-FILE should
provide the effect of (WITH-COMPILATION-UNIT (:OVERRIDE NIL) ...)
around their code.
Any implementation-dependent extensions may only be provided
as the result of an explicit programmer request by use of
an implementation-dependent keyword. Implementations are forbidden
from attaching additional meaning to a conforming use of this
macro.
Note also that not all warnings are deferred. In some implementations,
it may be that none are deferred. This proposal only creates an
interface to the capability where it exists, it does not require the
creation of the capability. An implementation which does not do
deferred warnings may correctly implement this as expanding into PROGN.
Test Case:
(DEFUN COMPILE-FILES (&REST FILES)
(WITH-COMPILATION-UNIT ()
(MAPCAR #'(LAMBDA (FILE) (COMPILE-FILE FILE)) FILES)))
(COMPILE-FILES "A" "B" "C")
processes deferred warnings only after compiling all of A, B, and C.
Rationale:
This will make the development of portable system-construction tools
considerably more convenient.
Current Practice:
Lucid has a very similar facility, called WITH-DEFERRED-WARNINGS.
TI Explorer and Symbolics Genera have a similar facility, which they
call COMPILER-WARNING-CONTEXT-BIND.
Cost to Implementors:
In implementations which have no deferred warnings, there is no cost.
In implementations which have deferred warnings, the cost is probably
fairly small -- usually just a matter of writing interfacing the
proposed macro to an existing one.
Cost to Users:
None. This is a compatible addition.
Cost of Non-Adoption:
Portable system-construction tools would continue to print lots of
spurious warnings because they would have no way to tell the system
that a set of files was working together.
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
The ability to create a compilation unit other than a file is important.
Discussion:
Pitman and Benson support this addition.
One could imagine adding more options at a later date.
It was the opinion of the compiler committee that there was room for
expansion here to address issues like bounding the scope of global
proclamations, sharing compile-time environments across files, etc.
However, insufficient work was done on this to justify putting such
a thing into the standard. The only clear need we have at this time
was to defer warnings, but we chose a general name like
WITH-COMPILATION-UNIT rather than a specific name like Lucid's
WITH-DEFERRED-WARNINGS in order to encourage implementations to
experiment with other kinds of options under implementation-specific
keywords. Perhaps by the time of the next standard there will be
sufficient understanding of this area to warrant further elaboration
of this primitive.
Kim Barrett says:
I strongly oppose the behavior you proposed for compile and
compile-file. It is my belief that whether to override or not must be
controlled through an argument to the compile functions, with the
default being to override. Otherwise, all existing code which makes
use of the compile functions must be modified to protect itself by
wrapping a (with-compilation-unit (:override t) ...) around the calls
to the compiler.
Consider a stream system built on an object system which will compose
and compile functions on the fly on an as needed basis. It would be
very strange for the functions so generated while doing file io for
the user's compile-file to have any relationship with said
compile-file.
I agree with your position that implementation-dependent extensions
must be explicitly requested.
∂13-Mar-89 1634 X3J13-mailer summary of active cl-compiler issues
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 16:34:43 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA11546; Mon, 13 Mar 89 17:32:30 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02645; Mon, 13 Mar 89 17:32:27 -0700
Date: Mon, 13 Mar 89 17:32:27 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903140032.AA02645@defun.utah.edu>
To: x3j13@sail.stanford.edu
Reply-To: cl-compiler@sail.stanford.edu
Subject: summary of active cl-compiler issues
Here is a list of all the active cl-compiler issues. Writeups for
all of these were mailed out earlier today.
CLOS-MACRO-COMPILATION (**DRAFT** version 2)
Clarify compile-time behavior of CLOS defining macros.
Proposal MINIMAL
Proposal NOT-SO-MINIMAL
(Still under active discussion.)
COMPILE-ENVIRONMENT-CONSISTENCY (version 4)
What kinds of things can/must the compiler "wire in" to the code
it compiles?
Proposal CLARIFY
COMPILE-FILE-SYMBOL-HANDLING (version 2)
How does COMPILE-FILE tell LOAD what package to put symbols in?
Proposal CURRENT-PACKAGE
Proposal HOME-PACKAGE
Proposal REQUIRE-CONSISTENCY
COMPILED-FUNCTION-REQUIREMENTS (version 4)
What does the COMPILED-FUNCTION type imply? Do COMPILE and
COMPILE-FILE construct COMPILED-FUNCTIONs?
Proposal TIGHTEN
Proposal TIGHTEN-COMPILE
COMPILER-DIAGNOSTICS (version 9)
Clarify status and handling of errors and warnings signalled during
compilation.
Proposal USE-HANDLER
COMPILER-LET-CONFUSION (version 7)
The description of COMPILER-LET in CLtL is broken -- should we fix
it or eliminate it entirely?
Proposal REPAIR
Proposal ELIMINATE
COMPILER-VERBOSITY (version 6)
Mechanisms for controlling progress messages issued by the compiler.
Proposal LIKE-LOAD
CONSTANT-CIRCULAR-COMPILATION (version 7)
Must circular or recursive objects be compiled correctly? Must the
compiler preserve sharing of substructures?
Proposal NO
Proposal PRESERVE-SHARING-ONLY
Proposal YES
(Expect amendment to change error terminology.)
CONSTANT-COLLAPSING (version 5)
Should the compiler be allowed to "collapse" or coalesce constants
that satisfy a more general equivalence relationship than EQUAL?
Proposal GENERALIZE
CONSTANT-COMPILABLE-TYPES (version 8)
What types of objects can appear as quoted or self-evaluating constants
in compiled code?
Proposal SPECIFY
(Expect amendments to change requirements for functions.)
DEFCONSTANT-NOT-WIRED (**DRAFT** version 6)
How do you delcare a variable to be constant without giving the
compiler permission to make assumptions about its value?
(None of the proposals are ready to be voted on. This issue
is being distributed only for informational purposes.)
DEFINE-OPTIMIZER (version 5)
Provide a macro-like way of specifying source-level optimizations
on function calls.
Proposal NEW-FACILITY
DEFINING-MACROS-NON-TOP-LEVEL (version 8)
Are defining macros such as DEFUN meaningful in non-top-level locations?
Proposal ALLOW
EVAL-WHEN-NON-TOP-LEVEL (version 6)
What does EVAL-WHEN mean when it appears in non-top-level locations?
Proposal GENERALIZE-EVAL
Proposal GENERALIZE-EVAL-NEW-KEYWORDS
LOAD-TIME-EVAL (version 11)
Add a new special form, LOAD-TIME-VALUE.
Proposal R**2-NEW-SPECIAL-FORM
Proposal R**3-NEW-SPECIAL-FORM
(Proposal R**2-NEW-SPECIAL-FORM was approved at the January meeting,
but some additional suggestions were made after the meeting.)
MACRO-CACHING (version 2)
Is it legitimate to cache macro expansions?
Proposal DISALLOW
Proposal RESTRICT
MACRO-ENVIRONMENT-EXTENT (**DRAFT** version 3)
Do environment objects received as the &ENVIRONMENT argument to a
macro have dynamic or indefinite extent?
Proposal INDEFINITE
Proposal DYNAMIC
Proposal DYNAMIC-WITH-COPIER
(Still under active discussion.)
PROCLAIM-ETC-IN-COMPILE-FILE (**DRAFT** version 4)
Are top-level calls to PROCLAIM handled specially by the compiler?
Proposal YES
Proposal NO
Proposal NEW-MACRO
(New rewrite.)
QUOTE-SEMANTICS (version 2) (replaces QUOTE-MAY-COPY)
May COMPILE and EVAL construct equivalent copies of quoted or
self-evaluating constants, or must constants share structure with
the source code for the program? Do the constraints on what objects
are valid constants also apply to COMPILE and EVAL, or only to
COMPILE-FILE?
Proposal NO-COPYING
Proposal COPYING-ALLOWED-BUT-NO-CONSTRAINTS
Proposal SAME-AS-COMPILE-FILE
SAFE-CODE (version 1)
What does the "safe code" mean?
Proposal SAFETY-3
SYNTACTIC-ENVIRONMENT-ACCESS (**DRAFT** version 4)
Provide accessors and constructors for lexical environment objects.
Proposal SMALL
Proposal MEDIUM
Proposal LARGE
(New rewrite.)
WITH-COMPILATION-UNIT (version 3)
Provide a way to compile a group of files as a unit for the purposes
of error messages.
Proposal NEW-MACRO
∂13-Mar-89 1643 X3J13-mailer issue COMPILER-LET-CONFUSION, version 7
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89 16:43:27 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Mon, 13 Mar 89 19:39:46 EST
Date: Mon, 13 Mar 89 19:41 EST
From: Barry Margolin <barmar@Think.COM>
Subject: issue COMPILER-LET-CONFUSION, version 7
To: cl-compiler@sail.stanford.edu
Cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132314.AA02546@defun.utah.edu>
Message-Id: <19890314004109.1.BARMAR@OCCAM.THINK.COM>
Date: Mon, 13 Mar 89 16:14:26 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
In interpreters which do not do a semantic-prepass, it is necessary
to fully macroexpand the body. Assuming the presence of a
SYSTEM::MACROEXPAND-ALL primitive, the definition of COMPILER-LET
could look like:
(DEFMACRO COMPILER-LET (BINDINGS &BODY FORMS &ENVIRONMENT ENV)
(SETQ BINDINGS ;; Assure no non-atom bindings
(MAPCAR #'(LAMBDA (BINDING)
(IF (ATOM BINDING) (LIST BINDING) BINDING))
BINDINGS))
(PROGV (MAPCAR #'CAR BINDINGS)
(MAPCAR #'CDR BINDINGS)
(SYSTEM::MACROEXPAND-ALL `(PROGN ,@FORMS) ENV)))
Modulo some bugs in the code. Shouldn't the second-to-last line be:
(MAPCAR #'(LAMBDA (BINDING)
(eval (CaDR BINDING)))
BINDINGS)
(my additions are in lowercase)?
barmar
∂14-Mar-89 0859 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Faculty Meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Mar 89 08:59:05 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Tue 14 Mar 89 08:56:34-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA24539; Tue, 14 Mar 89 08:56:40 -0800
Date: Tue, 14 Mar 1989 8:56:38 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: ac@score
Subject: Faculty Meeting
Message-Id: <CMM.0.87.605897798.chandler@polya.stanford.edu>
Since we have a very long agenda for today's faculty meeting we will begin
PROMPTLY at 2:30.
∂14-Mar-89 0911 aaai@sumex-aim.stanford.edu Reminder/Council Mtg
Received: from sumex-aim.stanford.edu by SAIL.Stanford.EDU with TCP; 14 Mar 89 09:11:38 PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA10748; Tue, 14 Mar 89 09:04:18 PST
Date: Tue, 14 Mar 1989 9:04:17 PST
From: AAAI <aaai@sumex-aim.stanford.edu>
To: officers:;@sumex-aim.stanford.edu
Cc: aaai@sumex-aim.stanford.edu
Subject: Reminder/Council Mtg
Message-Id: <CMM.0.88.605898257.aaai@sumex-aim.stanford.edu>
{
For those who have not responded yet, could ~you please inform me of your
attention to attend the Council meeting, Thursday, March 30, at 1:30 pm
in room 220 in M Jacks Hall, SU.
Thanks,
Claudia
∂14-Mar-89 0938 CL-Compiler-mailer issue COMPILER-LET-CONFUSION, version 7
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 09:37:46 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556615; Tue 14-Mar-89 12:35:04 EST
Date: Tue, 14 Mar 89 12:35 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILER-LET-CONFUSION, version 7
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132314.AA02546@defun.utah.edu>
Message-ID: <19890314173505.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
I generally favor the COMPILER-LET-CONFUSION:REPAIR proposal, however
I have a couple of comments and questions. Also of course I would want
to see the typo that BarMar found fixed.
What is the interaction between proposals COMPILER-LET-CONFUSION
and DEFINE-OPTIMIZER? Neither proposal says anything about that
as far as I can see. I believe the body of a optimizer must be
executed in the same dynamic environment as the body of a macro.
Cost to Implementors:
In interpreters which do not do a semantic-prepass, it is necessary
to fully macroexpand the body.
This is not true. A possible implementation technique for such
interpreters, in fact the one I would use, is to save the COMPILER-LET
bindings in a slot in the interpreter's lexical environment in the form
of an alist, and to make the MACROEXPAND-1 function bind those bindings
with PROGV around its call to the macroexpander. Using this technique
instead of fully macroexpanding the body deals with some of the
objections to the REPAIR proposal, I believe. Also promoting this
technique in the proposal would remove the need for the discussion
section to address the side-issue of whether code analyzing programs can
or cannot be written portably (an important issue in its own right, but
not part this one).
Current Practice:
Some implementations have implemented the description in CLtL.
Users of those implementations (quite reasonably) can't figure how to
use COMPILER-LET and so don't use it much.
Some implementations (the ones from which COMPILER-LET originally came)
continue to use their pre-CLtL semantics. These semantics are useful, though
incompatible with CLtL (which they largely consider to simply be in error).
Could you be more explicit about this? I was unable to figure out what you
are talking about, even after twice reading the introductory portion of the
proposal and the writeup in CLtL. I believe Symbolics Genera is one of those
implementations from which COMPILER-LET originally came and at the same time
implements COMPILER-LET exactly as CLtL specifies, so I must be missing some
important distinction. I'd like to see a precise description of these two
competing semantics and I'd also like to know which, if either, of them is
compatible with the REPAIR proposal.
∂14-Mar-89 0956 CL-Compiler-mailer issue DEFINE-OPTIMIZER, version 5
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 09:56:35 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556621; Tue 14-Mar-89 12:54:02 EST
Date: Tue, 14 Mar 89 12:54 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue DEFINE-OPTIMIZER, version 5
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132331.AA02562@defun.utah.edu>
Message-ID: <19890314175403.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
I generally like DEFINE-OPTIMIZER:NEW-FACILITY, but I would like
to suggest a couple of changes.
I'm not a fan of documentation strings, but shouldn't DEFINE-OPTIMIZER
allow them? Was their omission accidental or intentional?
Instead of returning two values from the body, I suggest returning one
value, or NIL to decline to optimize. If an optimizer wishes to
optimize into a form whose result is NIL, it should return (QUOTE NIL).
After all, if it wishes to optimize into a form whose result is FOO, it
has to return (QUOTE FOO), not FOO. The two values returned by
OPTIMIZE-EXPRESSION-1 are okay, since they are compatible with the two
values returned by MACROEXPAND-1. A reasonable alternative would be to
eliminate the two values at all levels, and also eliminate the special
casing of NIL, and simply specify that one declines to optimize by
returning the original form (compared with EQ). This will work but is
slightly more awkward for the optimizer writer, since &WHOLE would
have to be used. I'd accept this alternative if more people are in
favor of it, but I prefer special-casing NIL. I'd greatly prefer either
of those alternatives over what the proposal says now.
It isn't made clear whether OPTIMIZE-EXPRESSION returns one value
or two. It should be consistent with OPTIMIZE-EXPRESSION-1.
Using FLET and MACROLET shadow...
I assume it was only accidental that LABELS, GENERIC-LABELS, and
GENERIC-FLET were omitted from this list. I am unable to figure
out whether WITH-ADDED-METHODS should be included in this list
or not; I suspect not.
The similar Symbolics Genera facility allows more than one optimizer
to be defined for a given function; the optimizers are invoked in
unspecified order until one succeeds. This feature is actually
used, however I think it is okay to leave it out.
I agree with Barrett's comments quoted in the discussion section.
I'd like to see the proposal amended the way he suggests.
∂14-Mar-89 1005 CL-Compiler-mailer issue WITH-COMPILATION-UNIT, version 3
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 10:05:29 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556623; Tue 14-Mar-89 13:03:02 EST
Date: Tue, 14 Mar 89 13:03 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue WITH-COMPILATION-UNIT, version 3
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903140025.AA02634@defun.utah.edu>
Message-ID: <19890314180303.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
I oppose this because I don't think it's finished, however I expect I
would support it if it were finished. It may be that the amount of work
required to finish this is small and the proposal just needs amending.
I don't think it's acceptable to have something like this if its effect
is only defined for warnings, and its effect on compile-time
proclamations, compile-time macro definitions, compile-time defconstant
definitions, compile-time optimizer definitions, compile-time type
definitions, compile-time setf definitions, and compile-time CLOS
definitions is left unspecified.
I think lumping COMPILE and COMPILE-FILE together here reflects
confusion. COMPILE and COMPILE-FILE have very little to do with each
other, and I think it's clear that COMPILE should not be affected in any
way by WITH-COMPILATION-UNIT. Having COMPILE affected by
WITH-COMPILATION-UNIT is as unreasonable as having MACROEXPAND affected
by WITH-COMPILATION-UNIT, if you ask me. I think removing COMPILE would
address Barrett's complaint in the discussion section; that is, I think
having COMPILE-FILE not override an enclosing WITH-COMPILATION-UNIT is
correct.
∂14-Mar-89 1217 CL-Compiler-mailer **DRAFT** issue MACRO-ENVIRONMENT-EXTENT, version 3
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 12:17:12 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556715; Tue 14-Mar-89 15:09:52 EST
Date: Tue, 14 Mar 89 15:09 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: **DRAFT** issue MACRO-ENVIRONMENT-EXTENT, version 3
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132355.AA02585@defun.utah.edu>
Message-ID: <19890314200952.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
I strongly favor MACRO-ENVIRONMENT-EXTENT:DYNAMIC over any of the other four.
∂14-Mar-89 1232 CL-Compiler-mailer **DRAFT** issue PROCLAIM-ETC-IN-COMPILE-FILE (version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 12:32:34 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556743; Tue 14-Mar-89 15:29:24 EST
Date: Tue, 14 Mar 89 15:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: **DRAFT** issue PROCLAIM-ETC-IN-COMPILE-FILE (version 4)
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903140008.AA02608@defun.utah.edu>
Message-ID: <19890314202917.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO, primarily because this
allows programs to be clear about the scope of the proclamation:
whether they are making a proclamation for purposes of compile-file or
to affect the running Lisp. If you call the macro at top-level, you're
clearly doing it for compilation. If you call the function at any level,
you're clearly doing it with global scope.
In PROCLAIM-ETC-IN-COMPILE-FILE:NO there is no way to say whether a
PROCLAIM inside an (EVAL-WHEN (COMPILE...) ...) is intended to persist
after the compilation is over, which is just about the only reason
why I prefer PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO over :NO.
I'd like PROCLAIM-ETC-IN-COMPILE-FILE:NO better if it also proposed
to add an optional argument to PROCLAIM that expressed the intended
scope of the proclamation. I'd suggest NIL (the default) for the
global scope and the symbol COMPILE-FILE to limit it to the compilation.
Given this, users who liked DEFPROCLAIM could trivially write it
themselves.
The only thing PROCLAIM-ETC-IN-COMPILE-FILE:YES has going for it is
that it's the status quo, in a subset of implementations. I don't like it.
I agree with Barrett's comments quoted in the discussion section.
The proposal says:
As with other defining macros, it is
unspecified whether or not the compile-time side-effects of a
DEFPROCLAIM persist after the file has been compiled.
but never says this about PROCLAIM. In all three proposals,
this needs to be said about PROCLAIM. But as you can see from my
comments above, I would rather that we did not leave this unspecified.
The proposal says:
Current Practice:
The Symbolics compiler has special top-level handling for PROCLAIM,
although the details are not clear.
I'm not sure what you thought was not clear. Symbolics Genera does the
same thing that the current practice section says IIM does. In addition
(and I couldn't tell whether IIM does this too or not), the scope of the
PROCLAIM is only the compilation-unit if the PROCLAIM appears at
top-level, but is global and persists forever if the PROCLAIM appears in
an (EVAL-WHEN (COMPILE...) ...). We might change that.
∂14-Mar-89 1310 CL-Compiler-mailer issue DEFINING-MACROS-NON-TOP-LEVEL, version 8
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 13:09:32 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556774; Tue 14-Mar-89 15:58:28 EST
Date: Tue, 14 Mar 89 15:58 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue DEFINING-MACROS-NON-TOP-LEVEL, version 8
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132333.AA02565@defun.utah.edu>
Message-ID: <19890314205826.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor DEFINING-MACROS-NON-TOP-LEVEL:ALLOW except for one thing.
This sentence appears in the proposal but does not appear to have
any relation to the main issue:
The order in which
non-top-level subforms of a top-level form are processed by the
compiler is explicitly left unspecified.
I can't figure out what this means and the example in the rationale
section that purports to explain this does not shed any light, since in
the example there is no change of order of evaluation. I wouldn't be
surprised if I opposed this if I did understand what it means. Can we
deal with this as a separate issue? In fact the whole point (3) of the
proposal should be moved. That issue should also discuss whether there
are any constraints on whether one top-level form is processed before
the next top-level form is read, in case the one form changes package,
changes readtable, defines a read-syntax, or defines a structure used in
#S read-syntax.
Also, when you say:
Clarify
that all defining macros which create functional objects (including
DEFMACRO, DEFTYPE, DEFINE-SETF-METHOD, and the complex form of
DEFSETF, as well as DEFUN) must ensure that those functions are
defined in the lexical environment in which the defining form is
evaluated.
I strongly believe that MACROLET must be consistent with this, which
would be a change. Has that been dealt with as a separate issue? If
not, it should either be added to this issue or brought up as a
separate issue, with the interdependency noted in both writeups to
minimize the chance of an inconsistent vote.
∂14-Mar-89 1326 CL-Compiler-mailer issue COMPILE-FILE-SYMBOL-HANDLING, version 2
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 13:25:58 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556792; Tue 14-Mar-89 16:23:12 EST
Date: Tue, 14 Mar 89 16:23 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILE-FILE-SYMBOL-HANDLING, version 2
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132312.AA02542@defun.utah.edu>
Message-ID: <19890314212313.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor COMPILE-FILE-SYMBOL-HANDLING:CURRENT-PACKAGE.
COMPILE-FILE-SYMBOL-HANDLING:HOME-PACKAGE seems superficially simpler,
but my experience when we tried it at MIT indicates that it does not
work very well. Too often a symbol that had been moved from one package
to another, or had its export status changed, would be silently moved
back to its original package by loading a file. I sort-of agree with
JonL's comment at the end of the discussion section: if we can't agree
on one solution to his issue, I think that in practice there would be
little harm to portable programs if we left it unspecified. The issue
really affects development environments much more than it affects the
language in which portable programs are written, although it does have
some effect on that as well.
∂14-Mar-89 1340 CL-Compiler-mailer issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 13:40:33 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 556802; 14 Mar 89 16:37:50 EST
Date: Tue, 14 Mar 89 16:37 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132250.AA02499@defun.utah.edu>
Message-ID: <19890314213750.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
All the things I didn't like in version 3 have been fixed.
I would favor COMPILE-ENVIRONMENT-CONSISTENCY:CLARIFY if one change
were made. The proposal says:
Except where some other behavior is explicitly stated, when
the compiletime and runtime definitions are different, it is
unspecified which will prevail within the compiled code.
This means that either the compiletime or the runtime definition
will prevail, but nothing else can happen. It must also be
permissible to signal an error complaining about the discrepancy.
∂14-Mar-89 1351 CL-Compiler-mailer issue SAFE-CODE, version 1
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 13:51:31 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556829; Tue 14-Mar-89 16:49:05 EST
Date: Tue, 14 Mar 89 16:49 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue SAFE-CODE, version 1
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131726.AA02193@defun.utah.edu>
Message-ID: <19890314214907.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
I agree with SAFE-CODE:SAFETY-3.
I disagree with the usage (in the examples) of "unsafe code" to mean
"all code where the OPTIMIZE quality of SAFETY is not 3." I believe
that "unsafe code" should mean code that is actually unsafe, not code
that an implementation is permitted to treat as unsafe if it wishes. I
believe there should be no portable way to write unsafe code. This is
only a matter of wording. If we need a shorter term for "all code where
the OPTIMIZE quality of SAFETY is not 3" I would suggest "potentially
unsafe code."
∂14-Mar-89 1357 CL-Compiler-mailer issue COMPILER-VERBOSITY, version 6
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 13:56:56 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556842; Tue 14-Mar-89 16:54:22 EST
Date: Tue, 14 Mar 89 16:54 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILER-VERBOSITY, version 6
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131546.AA02078@defun.utah.edu>
Message-ID: <19890314215423.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
I like COMPILER-VERBOSITY:LIKE-LOAD. This fixes all of the
problems I had with the version 5 proposal.
Like BarMar, I question the need for either of :PRINT and :VERBOSE in
either of LOAD and COMPILE-FILE. But that might be my own cultural
bias, due to the type of systems I use, where it's easy to see what's
going on inside. If other people claim they need these, I'll believe
them.
∂14-Mar-89 1419 X3J13-mailer Issue: ERROR-NOT-HANDLED (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 14:19:42 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 14:03:50 PST
Date: 14 Mar 89 14:02 PST
From: masinter.pa@Xerox.COM
to: X3J13@sail.stanford.edu
Subject: Issue: ERROR-NOT-HANDLED (Version 1)
reply-to: cl-cleanup@sail.stanford.edu
line-fold: NO
Message-ID: <890314-140350-1917@Xerox>
Cleanup issues for the next meeting will be tricking out over the next
week.
This issue was distributed prior to the October 1988 meeting,
but not voted on.
!
Issue: ERROR-NOT-HANDLED
References: Interactive Condition Handling (Condition System, Rev 18, p19)
Category: CLARIFICATION/CHANGE
Edit history: 25-Sep-88, Version 1 by Pitman
Problem Description:
For delivery purposes, some implementations will want to leave out
major sections of runtime support in programs that do not require
them. The debugger is one such section.
However, since ERROR may be called implicitly by a number of Common
Lisp built-in functions, and since the condition system as currently
described insists that the interactive debugger be entered if a
condition is unhandled, the interactive debugger must be retained in
a saved image of any program that might signal an error unless the
compiler can prove that the error will never go unhandled. This
may be undesirable in some cases and may cause unnecessary bloating
of the saved image.
Proposal (ERROR-NOT-HANDLED:PERMIT-TERMINATION):
Permit implementors to designate an implementation-specific mechanism
for asking that unhandled errors cause `termination of the running
program' rather than entry into the system's debugger.
Implementations choosing to offer such a facility must clearly define
the nature and scope of such program termination, since the concept
of `program termination' is an ill-defined concept in present-day
Common Lisp.
Even when program termination rather than debugger entry would be
the ultimate effect of an unhandled error, the value of
*DEBUGGER-HOOK* (if non-NIL) must be called to provide programmers
the ability of customized debugging.
All implementations must at least provide the option of a system
debugger for use in program development.
Test Case:
(ERROR "Foo"), if unhandled, must now enter the debugger.
Under this proposal, it might also `terminate program execution'
in implementations which choose to provide such a facility and to
clearly define that concept.
Rationale:
Although technically an incompatible change, we're dealing at
the very edge of what the user can expect from the system. Once
an error is signalled and not handled, we're in the domain of
implementation-dependent effect anyway.
Current Practice:
Probably no one does this yet.
Cost to Implementors:
None. This change is upward compatible with existing implementations.
Cost to Users:
None.
Cost of Non-Adoption:
Saved Lisp images might be forced to be gratuitously larger than
they need to be in some implementations.
Benefits:
Addressing this issue will make Lisp more able to compete with
other languages which permit small saved images to result from
small user programs.
Aesthetics:
No significant impact.
Discussion:
This change was requested by Christian Queinnec of France
(queinnec@inria.inria.fr). Pitman supports the change.
∂14-Mar-89 1438 CL-Compiler-mailer issue COMPILER-DIAGNOSTICS, version 9
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 14:38:21 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556909; Tue 14-Mar-89 17:35:56 EST
Date: Tue, 14 Mar 89 17:35 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILER-DIAGNOSTICS, version 9
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131545.AA02075@defun.utah.edu>
Message-ID: <19890314223550.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor COMPILER-DIAGNOSTICS:USE-HANDLER, but there are two
things that I think need to be changed:
Conditions of type WARNING may be signalled by the compiler in
situations where ... the compiler can determine
that a situation that "is an error" would result at runtime.
We don't use the term "is an error" any more, do we? In the old
CLtL terms, I think both "is an error" and "signals an error"
situations would justify a warning. I think this part should
be updated to the new error terminology and also should state that
all error situations justify warnings. Of course explicit calls
to the function ERROR don't justify warnings; I don't know whether
the proposal can be phrased in such a way as to make that clear,
or whether it will have to be left to common sense.
(3) Require COMPILE and COMPILE-FILE to handle the ABORT restart by
aborting the smallest feasible part of the compilation.
I think this is wrong. The only documentation of the ABORT restart
that I could find says
The purpose of the ABORT restart is generally to allow return to the
innermost ``command level.''
I agree with this, and I believe it means that it is wrong for any
function other than one that establishes a read-eval-print loop or
a command-level to establish an ABORT restart. It would be useful
to have some restart that aborts a portion of the compilation, but
it should be given some other name.
∂14-Mar-89 1505 CL-Cleanup-mailer Issue: ERROR-NOT-HANDLED (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 15:04:58 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556941; Tue 14-Mar-89 18:02:30 EST
Date: Tue, 14 Mar 89 18:02 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ERROR-NOT-HANDLED (Version 1)
To: cl-cleanup@sail.stanford.edu
cc: X3J13@sail.stanford.edu
In-Reply-To: <890314-140350-1917@Xerox>
Message-ID: <19890314230224.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
ERROR-NOT-HANDLED:PERMIT-TERMINATION is okay with me. I would
also support a proposal to replace "the condition system as currently
described insists that the interactive debugger be entered if a
condition is unhandled" with wording that allowed implementations
to do whatever they want, with perhaps an implementation note that
many implementations prefer an interactive debugger.
∂14-Mar-89 1544 CL-Compiler-mailer **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Received: from YUKON.SCRC.Symbolics.COM (SCRC-YUKON.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 15:44:06 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 438041; Tue 14-Mar-89 18:42:58 EST
Date: Tue, 14 Mar 89 18:41 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903140019.AA02631@defun.utah.edu>
Message-ID: <19890314234118.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
This looks good so far. A few comments that might help you
along with the draft:
VARIABLE-KIND should return the same second value that FUNCTION-KIND
returns.
It's a good idea to avoid the ambiguous word "may" and say "might",
"must", or "is permitted to".
I would assume that VARIABLE-TYPE is not required to return the
exact declared type specifier, but could return another type
specifier that is equivalent, or possibly another type specifier
that is a supertype. An implementation that canonicalizes type
declarations would do this. For example, if A was declared
(INTEGER 0 4999), VARIABLE-TYPE might return that list, another
list that was EQUAL to it but not EQ, the list (INTEGER (-1) (5000)),
the symbol FIXNUM, or perhaps something else. Similarly OR's and
AND's might be reduced to simpler type specifiers in an implementation
dependent way. If, on the other hand, VARIABLE-TYPE is not permitted
to do this, but must return the exact type specifier used in the
declaration, that would be okay, but should be stated explicitly.
Similar comments apply to FUNCTION-FTYPE of course.
I assume AUGMENT-ENVIRONMENT is permitted to share structure with
its env argument, although the proposal says "a copy of ENV".
The :MACRO argument to AUGMENT-ENVIRONMENT shouldn't look like the CADR
of a MACROLET special form, instead it should be a list of lists (name
function). That is, the expander functions should be supplied in the
form of functions rather than in the form of the source text used by
MACROLET. Your rationale argues against this but I strongly believe
that the rationale is wrong. I wouldn't mind seeing the parsing portion
of MACROLET made available as a separate function.
No way is provided to retrieve declarations other than SPECIAL, TYPE,
FTYPE, and LEXICAL (if PROCLAIM-LEXICAL passes). I think all
declarations should be retrievable, but OPTIMIZE declarations seem
particularly useful to retrieve in macros or optimizers that expand into
different code depending on the safety level or the speed/space
tradeoff. The irregular structure of declarations makes retrieving
them a bit complex, but here's my suggestion:
DECLARATION decl-type name &optional env [Function]
decl-type is a symbol. The interpretation of name depends
on decl-type. If a declaration of that type and name is
in force in the specified environment, it is returned, otherwise
NIL is returned. The following decl-types are specified,
additional implementation-dependent types could be added:
INLINE function-name => T or NIL
NOTINLINE function-name => T or NIL
IGNORE variable-name => T or NIL
OPTIMIZE quality => integer
DECLARATION decl-type => T or NIL
The possible interpreter implementation of COMPILER-LET I mentioned
in another message earlier today would seem to require another
keyword argument to AUGMENT-ENVIRONMENT. Does this mean that we
have to dictate some particular interpreter implementation of
COMPILER-LET? I'm unsure.
Symbolics Genera includes an undocumented internal macro, used
quite a bit in the implementation of the interpreter and code
analyzers, that could have been called WITH-AUGMENTED-ENVIRONMENT,
taking keywords like AUGMENT-ENVIRONMENT and also body forms,
and producing an environment with dynamic extent bound to a
variable within the body forms. Would it be useful to have this
too, or instead of AUGMENT-ENVIRONMENT? I'm unsure.
On SYNTACTIC-ENVIRONMENT-ACCESS:MEDIUM, my feeling today is that
this should be left out for now, even though I think we will want
something like it later, at the same time that CLOS metaobjects
go in.
Ditto for SYNTACTIC-ENVIRONMENT-ACCESS:LARGE.
∂14-Mar-89 1555 X3J13-mailer LETTER BALLOT -- Sun Microsystems
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 15:55:09 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
id AA21551; Tue, 14 Mar 89 15:16:32 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA11449; Tue, 14 Mar 89 15:12:40 PST
Received: by clam.sun.com (4.0/SMI-4.0)
id AA26931; Tue, 14 Mar 89 15:16:13 PST
Date: Tue, 14 Mar 89 15:16:13 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903142316.AA26931@clam.sun.com>
To: chapman%aitg.DEC@decwrl.dec.com
Subject: LETTER BALLOT -- Sun Microsystems
Cc: kempf%clam@Sun.COM, peck%clam@Sun.COM, sgadol%clam@Sun.COM,
x3j13@sail.stanford.edu
This is the Sun Microsystems vote.
________________________________________________________________________
Issue or section name | Version | Y | I | A |
------------------------------------------------------------------------
CUT-OFF-DATES | 4 | | I | |
------------------------------------------------------------------------
ERROR-TERMINOLOGY | 5 | | I | |
------------------------------------------------------------------------
FONTS | 2 | Y | | |
------------------------------------------------------------------------
TOC | 1 | Y | | |
------------------------------------------------------------------------
Section 1.8 | 5.8 | Y | | |
------------------------------------------------------------------------
Section 2.3 | 5.8 | Y | | |
------------------------------------------------------------------------
Section 2.4 | 5.8 | Y | | |
------------------------------------------------------------------------
Section 2.5 | 5.8 | | | A |
------------------------------------------------------------------------
Section 6.1 | 5.8 | | I | |
------------------------------------------------------------------------
Overall, I'm impressed with the work that has been done on
writing the standard, but not entirely comfortable with the process
I can see for getting from where we are to an actual standard.
CUT-OFF-DATES
I have both general and specific comments about the CUT-OFF-DATES
proposal. The general comments first:
The cutoff dates question causes me some discomfort, and I think
that is because the proposal is not as explicit as it might be.
First, how about stating what the goal for 12/89 is? E.g. a
draft standard approved by X3J13 and ready for release and
outside comments.
Second, as I understand it, the "final changes" dates are for
final changes from the selected reviewers for each section of
the standard, though this is not stated.
The process, as I understand it, is that a set of reviewers will
read each section (or set of tool descriptions) carefully and
submit corrections, etc.. The full committee will then vote on
these.
A proper review will need to be done by subject rather than by sections
of the alphabet. In fact at least one person at Sun has volunteered to
work on a particular subject. Note that Moon expects Symbolics
internal reviewers to do likewise. To me that implies the catalog of
tools must be voted on by subject rather than alphabetically, so I
recommend reorganizing those cutoff dates and votes by subject.
Moon suggests that it will take "several months" for Symbolics
to review the draft standard, and that the availability of
the cleanup process will be important for fixing problems
in the statement of the draft standard. I second this.
Being active in the compiler committee, I feel confident that a
well-constructed section on compilation will *not* be ready by
4/22/89. We need to bring the compiler work to a conclusion as close
to that date as we can, though, even if all is not perfect. The full
committee needs to help make this happen. (Thanks especially to David
Moon for his recent input.)
ERROR-TERMINOLOGY
The error terminology is OK, except for "consequences
are unspecified". That concept is broken, though it
has serious defenders. For example, Dick Gabriel says,
"If we were to drop this term, then every time we are
``explicitly vague'' a valid possibility is that a fatal
error can occur. How is it any better to say that what happens
when some operation happens is ``explicitly vague''."
A typical area of "explicit vagueness" is the destructive operations
on lists. The explicit vagueness here is quite limited. For
some operations any top level cell of certain lists may or may
not be modified. Similar statements apply to other operations.
The consequences are far from being unspecified but harmless.
They are CONSTRAINED but meaningful.
In other situations we may say that order of certain actions
is unspecified or we may say that a side effect may or may not
occur. (For example, numerical operations may be performed
in any of various orders.) All of these are appropriate ways
to state a specification.
Maybe someone will make me suddenly see the light and I'll realize
how silly I've been, but so far the idea of consequences being
"unspecified but harmless" seems more like a witticism than
a useable idea.
SECTION 6.1
Under "Other Information", many of the terms are actually
type specifiers. Wouldn't it be better to say that if a name
is the same as a type specifier, that argument must satisfy
the type specifier?
arguments to the function -- unclear to me
boolean -- I presume this are to be arguments where
all non-NIL values are *treated* alike.
Note that for macros we truly specify *syntax* (at least
for some, e.g. defstruct. For most functions we actually
give a lambda list.
p6-8, item 2b, the keyword :test-not has been flushed from
the sequence functions.
∂14-Mar-89 1610 X3J13-mailer Re: Issue: UNSOLICITED-MESSAGES
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 14 Mar 89 16:09:57 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa07509; 14 Mar 89 18:01 GMT
Date: Tue, 14 Mar 89 17:58:24 GMT
Message-Id: <8289.8903141758@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: UNSOLICITED-MESSAGES
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>, barmar@think.com
Cc: chapman <@decwrl.dec.com:chapman@aitg.dec>, x3j13@sail.stanford.edu
> Why is this problem unique to Lisp? Is there any wording in the C
> standard that explicitly prohibits malloc() from causing output? I
> doubt it, yet I don't think they find this disturbing.
>
> Maybe it's because C people have traditionally been willing to settle
> for less. :-) Seriously, I think it's a clear hole in their standard.
> People would probably flame if things that weren't documented as doing
> I/O were to suddenly start doing it.
As far as I know, the C standard also doesn't say that assignment
doesn't print out "I'm doing an assignment" or, indeed, that y = 6
doesn't also assign 17 to xyzzy. But does it need to make explicit
prohibitions?
The C standard says "In the abstract machine, all expressions are
evaluated as specified by the semantics." Presumably there is an
implication that it doesn't do random other things.
-- Jeff
∂14-Mar-89 1629 CL-Compiler-mailer issue CONSTANT-COMPILABLE-TYPES, version 8
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 16:29:32 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557038; Tue 14-Mar-89 19:27:03 EST
Date: Tue, 14 Mar 89 19:27 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue CONSTANT-COMPILABLE-TYPES, version 8
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131612.AA02083@defun.utah.edu>
Message-ID: <19890315002703.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
I apologize in advance for the length of this message.
This is good except for a few typos and the controversial business about
functions. I'd really like to see another round of editing to clean up
these problems before we're asked to vote on this.
I suggest moving everything having to do with functions to a
separate proposal. What's currently in the body of the proposal for
functions does not make any sense to me. I basically agree with the
comments from both Loosemore and Gabriel about this quoted in the
discussion section. However, we need to be careful when we discuss this
to distinguish between a function as a constant in compiled code, and a
form whose result is a function appearing in compiled code. The former
is `(quote ,#'(lambda ...)), the latter is `#'(lambda ...). The meaning
of the latter is clear, of course, and a useful question would be
whether it can fully satisfy the need for functions in compiled code and
eliminate any demand for the former.
I've said this before, but I still think the proposal would be
easier to understand if it explicitly dealt separately with
(1) relation of objects in the input of COMPILE-FILE to corresponding
objects in the result of LOAD of the output of COMPILE-FILE.
(2) relation of two objects in the output of a single COMPILE-FILE.
(3) relation of two objects in the output of two different COMPILE-FILEs.
instead of smushing these together in a fuzzy way. Look at the discussion
of uninterned symbols, for example: I found it incomprehensible.
Typos:
For any object that
appears in a constant, but is not supported by the language as part of
a constant, the behavior of the compiler is unspecified; either the
the compiler and/or loader will handle that constant (in an
implementation-dependent manner) or the compiler will detect the
situation and signal an error.
This says that the behavior of the compiler is unspecified and then
proceeds to specify it!
Because hash keys can be aggregate objects and because we treat hash
tables as unordered sets of <key, value> pairs, similarity of hash
tables is more complex. See under "Hash Tables", below, for the
definition.
I have no idea how this paragraph got into the middle of the discussion
of uninterned symbols.
References to packages are permitted in any constant.
This sentence is redundant, or else it implies that references to some
other types are permitted in some constants but not in other constants,
which I don't think you intended.
At load time, the package becomes the same as returned by
I don't know what it means for a package to "become". I think
this is just fractured syntax, though. See again my suggestion
for distinguishing the three types of similarity, which I think
indicates how to rewrite this sentence to be clear.
Under hash table:
The table's test is unchanged also.
Unchanged from what? I think what this was supposed to say was
that the table's test is a "basic attribute."
Consider a hash table as an unordered set of key and
value pairs. Two hash tables are similar as constants
exactly if there is a one-to-one correspondence between
the key and value pairs of each and a one-to-one
correspondence between the uninterned symbols of each
such that the two keys of each corresponding pair are
similar as constants and the two values are also similar
as constants. The correspondence of uninterned symbols
must be consistent with the correspondence defined for
the entire set of constants in the file.
This paragraph is totally garbled. If you took out the
stuff about uninterned symbols it might make sense.
Structure, Standard-object
<<There is a cl-cleanup issue, LOAD-OBJECTS, pending
which proposes a mechanism for dealing with objects.>>
For structure instances with no method defined at compile
time for MAKE-LOAD-FORM, the slot values and the name of
structure type (a symbol reference) are recorded by the
compiler and reconstructed by the loader.
The text not enclosed in french quotation marks directly contradicts
the LOAD-OBJECTS proposal. It should be removed so we don't have two
proposals trying to talk about the same thing.
This sentence in the discussion section:
The full extension of the concept of coalescing of constants is to say
that they can be coalesced exactly when they are similar as constants.
seems to be in the wrong document, since this issue is not about
coalescing of constants and does not otherwise mention it, except
incidentally in connection with a bug in Coral Lisp.
∂14-Mar-89 1636 CL-Compiler-mailer issue CONSTANT-COMPILABLE-TYPES, version 8
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 16:36:44 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557048; Tue 14-Mar-89 19:34:07 EST
Date: Tue, 14 Mar 89 19:34 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue CONSTANT-COMPILABLE-TYPES, version 8
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131612.AA02083@defun.utah.edu>
Supersedes: <19890315002703.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comments: Fix some typos in the definitions of the three concepts that I claim
should not be smushed together. Cris Perdue pointed out these typos
earlier, but I forgot to fix them before sending the first copy of this
message.
Message-ID: <19890315003408.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
I apologize in advance for the length of this message.
This is good except for a few typos and the controversial business about
functions. I'd really like to see another round of editing to clean up
these problems before we're asked to vote on this.
I suggest moving everything having to do with functions to a
separate proposal. What's currently in the body of the proposal for
functions does not make any sense to me. I basically agree with the
comments from both Loosemore and Gabriel about this quoted in the
discussion section. However, we need to be careful when we discuss this
to distinguish between a function as a constant in compiled code, and a
form whose result is a function appearing in compiled code. The former
is `(quote ,#'(lambda ...)), the latter is `#'(lambda ...). The meaning
of the latter is clear, of course, and a useful question would be
whether it can fully satisfy the need for functions in compiled code and
eliminate any demand for the former.
I've said this before, but I still think the proposal would be
easier to understand if it explicitly dealt separately with
(1) relation of objects in the input of COMPILE-FILE to corresponding
objects in the result of LOAD of the output of COMPILE-FILE.
(2) relation of two objects in the result of LOAD of the output
of a single COMPILE-FILE.
(3) relation of two objects in the result of LOAD of the output
of two different COMPILE-FILEs.
instead of smushing these together in a fuzzy way. Look at the discussion
of uninterned symbols, for example: I found it incomprehensible.
Typos:
For any object that
appears in a constant, but is not supported by the language as part of
a constant, the behavior of the compiler is unspecified; either the
the compiler and/or loader will handle that constant (in an
implementation-dependent manner) or the compiler will detect the
situation and signal an error.
This says that the behavior of the compiler is unspecified and then
proceeds to specify it!
Because hash keys can be aggregate objects and because we treat hash
tables as unordered sets of <key, value> pairs, similarity of hash
tables is more complex. See under "Hash Tables", below, for the
definition.
I have no idea how this paragraph got into the middle of the discussion
of uninterned symbols.
References to packages are permitted in any constant.
This sentence is redundant, or else it implies that references to some
other types are permitted in some constants but not in other constants,
which I don't think you intended.
At load time, the package becomes the same as returned by
I don't know what it means for a package to "become". I think
this is just fractured syntax, though. See again my suggestion
for distinguishing the three types of similarity, which I think
indicates how to rewrite this sentence to be clear.
Under hash table:
The table's test is unchanged also.
Unchanged from what? I think what this was supposed to say was
that the table's test is a "basic attribute."
Consider a hash table as an unordered set of key and
value pairs. Two hash tables are similar as constants
exactly if there is a one-to-one correspondence between
the key and value pairs of each and a one-to-one
correspondence between the uninterned symbols of each
such that the two keys of each corresponding pair are
similar as constants and the two values are also similar
as constants. The correspondence of uninterned symbols
must be consistent with the correspondence defined for
the entire set of constants in the file.
This paragraph is totally garbled. If you took out the
stuff about uninterned symbols it might make sense.
Structure, Standard-object
<<There is a cl-cleanup issue, LOAD-OBJECTS, pending
which proposes a mechanism for dealing with objects.>>
For structure instances with no method defined at compile
time for MAKE-LOAD-FORM, the slot values and the name of
structure type (a symbol reference) are recorded by the
compiler and reconstructed by the loader.
The text not enclosed in french quotation marks directly contradicts
the LOAD-OBJECTS proposal. It should be removed so we don't have two
proposals trying to talk about the same thing.
This sentence in the discussion section:
The full extension of the concept of coalescing of constants is to say
that they can be coalesced exactly when they are similar as constants.
seems to be in the wrong document, since this issue is not about
coalescing of constants and does not otherwise mention it, except
incidentally in connection with a bug in Coral Lisp.
∂14-Mar-89 1651 CL-Compiler-mailer issue QUOTE-SEMANTICS, version 2
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 16:51:17 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557056; Tue 14-Mar-89 19:48:51 EST
Date: Tue, 14 Mar 89 19:48 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue QUOTE-SEMANTICS, version 2
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131721.AA02184@defun.utah.edu>
Message-ID: <19890315004852.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor QUOTE-SEMANTICS:NO-COPYING for two reasons:
(1) it's clearly more aesthetic.
(2) I can't support either of the other two proposals because they use
the words "copying" and "coalescing" without defining their meaning.
My position could be changed to
QUOTE-SEMANTICS:COPYING-ALLOWED-BUT-NO-CONSTRAINTS by adding definitions
for those two words and by a strong argument that the implementation
cost of QUOTE-SEMANTICS:NO-COPYING is too high, since I believe to some
extent JonL's argument (quoted in the discussion section) that EQL of
(some types of) constants does not matter.
I can't imagine any argument that would convince me to
support QUOTE-SEMANTICS:SAME-AS-COMPILE-FILE. I believe Kent's
arguments against it (quoted in the discussion section).
∂14-Mar-89 1700 CL-Compiler-mailer issue MACRO-CACHING, version 2
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:00:30 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557059; Tue 14-Mar-89 19:57:55 EST
Date: Tue, 14 Mar 89 19:57 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue MACRO-CACHING, version 2
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131647.AA02151@defun.utah.edu>
Message-ID: <19890315005756.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
I support MACRO-CACHING:DISALLOW. I'd like to point out that the
"correct" way to do macro caching is not mentioned anywhere in this
writeup. Perhaps that was justified because there is no portable way to
do it (an implementation can do it, but a user cannot), however I think
omitting it leaves a false impression.
The "correct" way to do macro caching is via a table inside the lexical
environment structure, which has very different properties from a table
keyed by the lexical environment structure, mentioned in the writeup.
I think a shorter writeup might be better. It could simply say that
there is no correct portable way to use *MACROEXPANSION-HOOK* to cache
macro expansions, and that there is no requirement that an implementation
call the macro expansion function more than once for a given form
and lexical environment. This prohibits the incorrect user code discussed
at some length in the existing writeup, leaves implementations license
to do macro caching correctly, and avoids a lot of unnecessary detail.
∂14-Mar-89 1704 CL-Compiler-mailer issue LOAD-TIME-EVAL, version 11
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:04:49 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 557069; 14 Mar 89 20:02:04 EST
Date: Tue, 14 Mar 89 20:02 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue LOAD-TIME-EVAL, version 11
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131631.AA02140@defun.utah.edu>
Message-ID: <19890315010205.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
I like LOAD-TIME-EVAL:R**3-NEW-SPECIAL-FORM.
∂14-Mar-89 1722 CL-Compiler-mailer issue CONSTANT-CIRCULAR-COMPILATION, version 7
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:21:59 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557096; Tue 14-Mar-89 20:15:39 EST
Date: Tue, 14 Mar 89 20:15 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue CONSTANT-CIRCULAR-COMPILATION, version 7
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131619.AA02090@defun.utah.edu>
Message-ID: <19890315011539.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor CONSTANT-CIRCULAR-COMPILATION:YES except that all references to
EQ should be changed to EQL. There is no reason to require
implementations to be careful about EQ of numbers and characters.
∂14-Mar-89 1731 X3J13-mailer Issue: GENSYM-NAME-STICKINESS (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:31:12 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 14:57:16 PST
Date: 14 Mar 89 14:56 PST
From: masinter.pa@Xerox.COM
Subject: Issue: GENSYM-NAME-STICKINESS (Version 1)
To: x3j13@SAIL.Stanford.EDU
reply-to: cl-cleanup@sail.stanford.edu
line-fold: no
Message-ID: <890314-145716-2049@Xerox>
Additional Comments include:
"... it's ... late to consider things like this ..."
"YAY!!! This is what "cleanup" is for. Go For It! "
"Sounds like a good idea to me."
!
Issue: GENSYM-NAME-STICKINESS
Forum: Cleanup
References: GENSYM (p169)
Category: CHANGE
Edit history: 14-Feb-89, Version 1 by Pitman
Problem Description:
Many people avoid use of the argument to GENSYM because the argument
is `sticky' and such stickiness can lead to confusion. The problem is
that if any application (usually a macro) uses the gensym argument at
all, then all applications are forced to. If they do not, they risk
finding that the `helpful' argument supplied in some previous call will
be harmful to them.
Proposal (GENSYM-NAME-STICKINESS:WASH-HANDS):
Define that if an optional argument is given to GENSYM, it does NOT
have a side-effect on GENSYM's internal state.
Rationale:
Conscientious programmers are forced now to write their own GENSYM
lookalikes because they know the system's GENSYM has an invasive
effect. This defeats the primary intended function of GENSYM, which
is to satisfy the most common idiomatic use of MAKE-SYMBOL.
The stickiness of the GENSYM prefix was an attempt to be gratuitously
compatible with Maclisp, at the expense of good programming pratice.
Users who need the old behavior of GENSYM can trivially implement
that behavior using MAKE-SYMBOL.
Test Case:
(CHAR-EQUAL (CHAR (SYMBOL-NAME (SECOND (LIST (GENSYM "A") (GENSYM)))) 0)
#\G)
=> NIL ;under CLtL
=> T ;under this proposal
Current Practice:
Symbolics Cloe and Genera are compatible with CLtL, so this would be an
incompatible change.
Cost to Implementors:
Very small.
Cost to Users:
Most uses of GENSYM do not depend on the stickiness of the name, so the
change would be compatible. In some cases, the change would be an
improvement. Even in the worst case where someone depends on stickiness,
it's extremely straightforward to write the couple of lines of code to
produce an application based on MAKE-SYMBOL that is at least as flexible
as GENSYM, and often moreso.
Cost of Non-Adoption:
Good programmers would avoid using the argument to GENSYM (or using
GENSYM altogether) in many situations where they ought not have to.
Benefits:
Gensyms which appear to convey information through their name would not
accidentally pop out and cause confusion in places where they oughtn't.
Aesthetics:
Unnecessary global state changes are hard to reason about. This would
be a small simplification.
Discussion:
Pitman claims to have written a non-sticky GENSYM function for nearly
every one of the dozen or so large systems that he's written or worked
on in the last decade in order to get around the stated problem.
Others have suggested similar experience.
Pitman supports the proposal.
----- End Forwarded Messages -----
∂14-Mar-89 1730 CL-Compiler-mailer issue COMPILED-FUNCTION-REQUIREMENTS, version 4
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:29:45 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 557112; 14 Mar 89 20:27:21 EST
Date: Tue, 14 Mar 89 20:27 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131544.AA02070@defun.utah.edu>
Message-ID: <19890315012722.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
I much prefer the option FLUSH, which was in version 2 but has been
removed. That option was to remove the COMPILED-FUNCTION type.
This type has no portable meaning and never should have existed.
I have no objection to the proposed specification of what the COMPILE
and COMPILE-FILE functions do, but it should be decoupled from the
COMPILED-FUNCTION type and discussed under the rubric of those two
functions. The parts about COMPILER-LET and EVAL-WHEN can probably be
removed (assuming the COMPILER-LET-CONFUSION proposal that eliminates
the possibility of COMPILER-LET binding any variables at run time
passes, and the EVAL-WHEN-NON-TOP-LEVEL proposal passes) since they are
redundant; there is never any interpeter/compiler difference for
COMPILER-LET or EVAL-WHEN any more.
∂14-Mar-89 1722 CL-Compiler-mailer issue CONSTANT-COLLAPSING, version 5
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:21:52 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557083; Tue 14-Mar-89 20:10:42 EST
Date: Tue, 14 Mar 89 20:10 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue CONSTANT-COLLAPSING, version 5
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131622.AA02093@defun.utah.edu>
Message-ID: <19890315011043.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
The proposal says:
State the an implementation is permitted to coalesce constants
appearing in code to be compiled if they are equivalent under the
relationship defined in proposal CONSTANT-COMPILABLE-TYPES:SPECIFY.
I can't understand what this means. The referenced proposal uses
the word "similar", not "equivalent". I'd support this alternate
wording:
Suppose that A and B are two objects used as quoted constants in the
input to COMPILE-FILE, and that A' and B' are the corresponding
objects used as constants in the result of loading the output of
that COMPILE-FILE. If A' is similar as a constant to both A and B,
then it is valid for A' and B' to be EQL even if A and B are not EQL.
This may still be too vague, since "objects in the input to
COMPILE-FILE" means not in the input text file, which doesn't contain
objects, but in the result of applying READ to the input file, and since
"corresponding objects" is not defined.
∂14-Mar-89 1731 X3J13-mailer Issue: COERCE-INCOMPLETE (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:31:00 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 14:29:58 PST
Date: 14 Mar 89 14:24 PST
From: masinter.pa@Xerox.COM
Subject: Issue: COERCE-INCOMPLETE (Version 3)
To: X3J13@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
line-fold: no
Message-ID: <890314-142958-1976@Xerox>
There are a couple of "additional comments" on the proposal
at the end.
!
Issue: COERCE-INCOMPLETE
Reference: COERCE (p50)
Category: ADDITION/CHANGE
Edit history: Version 1 of COERCE-INCOMPLETE, 26-Feb-88 by M. Ida
Version 1 of COERCE-FROM-TYPE, 20-Jun-88 by Pitman
Version 2 of COERCE-INCOMPLETE, 21-Nov-88 by Pitman
(consolidate previous two proposals)
Version 3 of COERCE-INCOMPLETE, 07-Mar-89 by Pitman
(eliminate unpopular proposal, two new options)
Problem Description:
COERCE is difficult to extend because ambiguities arise about the
source type of the coercion.
For example, if the symbol STRING were permitted as a second argument
to coerce, as in (COERCE NIL 'STRING), there would be two posssible
return values: "" or "NIL". The choice would be arbitrary and would
have to be specified by the documentation. No matter which was chosen,
it would probably turn out to be a problem for some applications at
some times.
Another example is (COERCE (CHAR-CODE #\A) 'STRING). This might
return the same as (FORMAT NIL "~D" (CHAR-CODE #\A)) -- "65" in
most ASCII-based implementations -- or it might return "A". Again,
the choice would be arbitrary.
There is clear desire on the part of the user community to lift some of
the existing restrictions on arguments to COERCE, but because of legitimate
concerns about ambiguities, the Common Lisp designers have thus far
refused to do so.
Unfortunately, the failure of COERCE to handle these cases means it is
very difficult to learn to use COERCE. And the fact that COERCE is not
easily learned contributes to difficulty in learning Common Lisp because
instead of a single coercion operator with general purpose semantics, a
number of very special purpose coercion operators must be learned instead.
Some middle ground needs to be found, which neither compromises the
clear semantics and portable nature of COERCE nor complicates COERCE
in a way that makes it unlearnable.
Also, some people have expressed a desire for COERCE to be more
`symmetric.' Usually they seem to mean that they want it to be the case
that if (COERCE x y) works, then (COERCE (COERCE x y) (TYPE-OF x))
should also work. Although this is not an essential desire, it would
certainly be nice to achieve.
Proposal (COERCE-INCOMPLETE:LIMITED-ARBITRARY-EXTENSION):
Define COERCE to accept the following equivalences:
1. (COERCE x 'STRING) == (STRING x)
2. (COERCE x 'PATHNAME) == (PATHNAME x)
3. (COERCE x 'RATIONAL) == (RATIONAL x)
Clarify that
4. (COERCE x 'FLOAT) == (FLOAT x)
Rationale:
Many users think of STRING, for example, as ``the way to coerce
something to a string'' and are baffled why COERCE and STRING
disagree on how to do this.
Such users think that if there's a moral battle to be waged
over how to coerce an object to a STRING, the battle has already
been lost by defining the STRING function -- that whatever
decision is made for STRING must also apply to COERCE for the
sake of simplicity.
Similar arguments can be made for PATHNAME, FLOAT, and RATIONAL.
Proposal (COERCE-INCOMPLETE:DEPRECATE):
Deprecate COERCE.
Rationale:
COERCE is not functionally necessary -- no operation that it does
cannot be done in some other way. As such, it is basically just
a matter of syntactic convenience, and perhaps isn't worth having
around if it will be the subject of endless debate. Deprecating
it would allow us to declare this issue a `dead end' and focus our
attention on matters of greater substance.
Current Practice:
Presumably No one implements either of the proposals at this time,
since none are compatible with CLtL.
Cost to Implementors:
COERCE: Small to moderate.
DEPRECATE: None.
Cost to Users:
COERCE: This is an incompatible change. (COERCE 'NIL 'STRING) => ""
but (STRING NIL) => "NIL". How many applications are impacted by
this change is not clear. It would be straightforward to shadow
COERCE with an alternate definition that did the old thing in
cases where people were worried. Once such cases have been
identified, rewriting
(COERCE X 'STRING)
as
(IF X (COERCE X 'STRING) "")
will suffice in most cases.
DEPRECATE: No immediate work would be needed, although many maintained
applications would get upgraded in order to use the primitives that
are `in vogue.'
Cost of Non-Adoption:
People will continue to see and debate the issues alluded to in
the Problem Description.
Benefits:
The cost of Non-Adoption will be avoided.
Aesthetics:
COERCE: Many people will probably see the idea of making
COERCE consistent with STRING, PATHNAME, FLOAT, and
RATIONAL as a clear improvement -- possibly outweighing
the costs of both an incompatible change and a decision
to arbitrarily favor one treatment over the other.
DEPRECATE: Some may take the deprecation of COERCE as an
aesthetic improvement because it eliminates the need to
debate this issue further. Others may see the
``de-centralization'' of coercion as a step backward.
Discussion:
Pitman supports COERCE-INCOMPLETE:LIMITED-ARBITRARY-EXTENSION.
Hopefully Moon and Masinter support it, too, since it's
basically patterned after a bunch of mail they were sending
back and forth.
A proposal to extend COERCE to permit a ``view type'' argument
was considered and rejected as too extreme to consider seriously
in the timeframe available.
Pierson suggests that COERCE ought to be a candidate for
generic function status.
Pitman thinks that making [two-argument] COERCE generic would
be a -very- bad idea but believes that his earlier proposal
involving a third `view type' argument might be able to
accomodate such extension.
!
Additional comments
I agree that this is ready to send out. The thing about
COERCE-INCOMPLETE:LIMITED-ARBITRARY-EXTENSION that strikes fear
into my heart is that it wipes out CLtL's simple statement that
any sequence type may be converted to any other sequence type,
and starts people asking questions like does
(coerce nil '(vector character)) => "" or "NIL"?
This concern is not reflected at all in the writeup.
I agree that this is ready to send out but I'm inclined to vote
no on both proposals and keep the (unsatisfactory) status quo.
----- -----
I believe that any change to the status quo is incomplete without
providing a coercion mechanism whose "viewpoint" is that of a sequence.
That is effectively what the current COERCE is, overloaded with those
types which do not conflict with SEQUENCE.
Because of the problem of differing viewpoints, I'm inclined to think
that COERCE should be shrunk down to only being a sequence coercion
function, and all other coercions should be handled by the appropriate
functions.
----- -----
∂15-Mar-89 0520 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 05:19:57 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAR 89 05:14:05 PST
Date: 15 Mar 89 05:13 PST
From: masinter.pa@Xerox.COM
to: X3J13@Sail.stanford.edu
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
reply-to: cl-cleanup@sail.stanford.edu
line-fold: NO
Message-ID: <890315-051405-3472@Xerox>
At the January '89 meeting, Version 4 of this issue was amended,
and then accepted.
We think there were some wording problems with the amendment,
in that it ended up not saying what we think was intended.
The amendment made some meaningful programs have undefined
behavior, and left the meaning of SIMPLE-ARRAY unclear.
After a good deal of work by the members of the cleanup committee,
we've arrived at the following version, which we would like
to submit to you for consideration as to whether it more
properly reflects the intent of the group.
!
Issue: ADJUST-ARRAY-NOT-ADJUSTABLE
References: ADJUST-ARRAY (p297), ADJUSTABLE-ARRAY-P (p293),
MAKE-ARRAY (pp286-289), simple arrays (p28, 289)
Category: CLARIFICATION
Edit history: 22-Apr-87, Version 1 by Pitman
15-Nov-88, Versions 2a,2b,2c by Pitman
02-Dec-88, Version 3 by Pitman
11-Jan-89, Version 4 by Pitman
16-Jan-89, Version 5, by Gabriel. Amended at the meeting to shorten.
23-Jan-89, Version 6, by Moon. Shorten without the bug introduced
by the amendment, add clarification of SIMPLE-ARRAY type.
15-Feb-89, Version 7, by Pitman. Minor changes per comments from
RPG and Dalton.
11-Mar-89, Version 8, by Pitman. Change category, add endorsements.
Problem Description:
The description of the :ADJUSTABLE option to MAKE-ARRAY on p288
says that ``the argument, if specified and not NIL, indicates that
it must be possible to alter the array's size dynamically after
it is created. This argument defaults to NIL.''
The description of the :ADJUSTABLE option does not say what
MAKE-ARRAY will do if the argument is unsupplied or explicitly NIL.
The description of ADJUSTABLE-ARRAY-P on p293 says that it is
true ``if the argument (which must be an array) is adjustable, and
otherwise false.'' However, the description of MAKE-ARRAY makes
it clear that this is not necessarily the same as asking if
the array was created with :ADJUSTABLE T. If ADJUSTABLE-ARRAY-P
returns NIL, you know that :ADJUSTABLE NIL was supplied (or no
:ADJUSTABLE option was supplied), but if ADJUSTABLE-ARRAY-P returns
T, then there is no information about whether :ADJUSTABLE was used.
The description of ADJUST-ARRAY on pp297-298 says that it is
``not permitted to call ADJUST-ARRAY on an array that was not
created with the :ADJUSTABLE option.'' This is inconsistent with
ADJUSTABLE-ARRAY-P.
A problem which comes up in practice is that some programmers
expect runtime error checking if they have done
(MAKE-ARRAY ... :ADJUSTABLE NIL) and they later try to adjust
the array using ADJUST-ARRAY.
The definition of the SIMPLE-ARRAY type and its subtypes needs
clarification of its relationship to adjustability.
Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE:CLARIFY):
1. ADJUSTABLE-ARRAY-P is true of all arrays created with a true
:ADJUSTABLE option to MAKE-ARRAY. Whether ADJUSTABLE-ARRAY-P is
true of some other arrays is unspecified.
2. If MAKE-ARRAY is called with the :ADJUSTABLE, :FILL-POINTER,
and :DISPLACED-TO arguments each either unspecified or false, the
resulting array is a simple array. (This just repeats what CLtL
says on page 289, it's here to aid in understanding the next point.)
3. If MAKE-ARRAY is called with one or more of the :ADJUSTABLE,
:FILL-POINTER, or :DISPLACED-TO arguments true, whether the
resulting array is simple is unspecified.
4. ADJUST-ARRAY ``should signal'' an error if ADJUSTABLE-ARRAY-P
of its first argument is false. ADJUST-ARRAY must not signal an
`array not adjustable' error if ADJUSTABLE-ARRAY-P of its first
argument is true.
5. The value of ADJUSTABLE-ARRAY-P on a simple array is unspecified.
Note: ``should signal'' is taken from the new error terminology.
It means that in ``safe code'' (code compiled with highest safety)
an error must be signalled, but that in unsafe code (code not compiled
with highest safety), an error might or might not be signalled.
Clarifications and Logical Consequences:
a. Whether an array can be both simple and adjustable is unspecified.
b. There is no specified way to create an array for which ADJUSTABLE-ARRAY-P
definitely returns NIL.
c. There is no specified way to create an array that is non-simple.
d. This legitimizes ADJUSTABLE-ARRAY-P as an appropriate predicate to
determine whether ADJUST-ARRAY will reliably succeed.
e. If ADJUST-ARRAY is invoked on an array that was created without
supplying :ADJUSTABLE true, an `array not adjustable' error
``should be signalled'' unless ADJUSTABLE-ARRAY-P returns true on
that array (in which case it must not signal an `array not adjustable'
error).
Rationale:
This effectively makes the status quo explicit. This preserves the
raison d'etre of simple arrays, which is to provide a portable interface
to implementation-dependent specialized arrays that trade decreased
functionality for faster access.
Specifying the points left unspecified (requiring all simple arrays to be
non-adjustable and all adjustable arrays to be non-simple) would require
large changes to some implementations and would be of little benefit to
users, merely making one kind of nonconforming program fail in all
implementations instead of failing only in some implementations. The
argument here is not that the error checking would not be useful for
developers of portable code, but only that the cost of introducing that
error checking would be exceedingly high for some implementations.
Users need to know that certain arrays are simple, so they can put in
declarations and get higher performance, but users have no need to be
able to create arrays that are definitely non-simple (for lower
performance) or definitely non-adjustable (to cause errors).
Examples:
1. The following program is conforming. It is unspecified which branch
of the IF it follows.
(defun double (a)
(if (adjustable-array-p a)
(adjust-array a (* (length a) 2))
(let ((new (make-array (* (length a) 2))))
(replace new a :end1 (length a))
new)))
(double (make-array 30))
2. The following program is conforming. In no implementation is the
type declaration violated.
(let ((a (make-array 100)))
(declare (simple-array a))
(frob a))
Current Practice:
Probably everyone is compatible with this proposal.
Symbolics Genera makes :ADJUSTABLE NIL arrays adjustable in most cases,
and ignores adjustability in deciding whether an array is simple,
and is compatible with this proposal.
Lucid, IIM, and Symbolics Cloe make :ADJUSTABLE NIL arrays non-adjustable
in all cases, and make all arrays non-simple unless the Common Lisp
language requires them to be simple, and are compatible with this proposal.
Cost to Implementors:
It's in principle possible that some implementation would have to change,
but in practice there are no known implementations that would have to change.
Cost to Users:
None. This is a fully compatible change from the user's standpoint.
Benefits:
Users would know what to expect.
Non-Benefits:
Users who expect adjusting arrays created with :ADJUSTABLE NIL to signal
an error would not get the desired error checking.
Aesthetics:
Most people believe the status quo is unaesthetic. Having an aspect of
the language explicitly unspecified is more aesthetic than having it
implicitly unspecified on account of vague or inconsistent documentation.
Discussion:
Pitman, Moon, Gabriel, and Steele support this amended proposal.
MACSYMA ran into portability problems due to the status quo.
If the issue had been documented, that would have helped.
Encouraging implementations that are able to at least make
(MAKE-ARRAY ... :ADJUSTABLE NIL) create non-adjustable arrays
where possible would help, too.
We considered proposals to incompatibly change this primitive in a
variety of ways, but the community was very split with strong proponents
and opponents of each alternate proposal.
The overriding concern driving this proposal is that Symbolics
has asserted that most of the other really interesting proposals would
likely involve a sizable cost to implementors (and their installed bases)
to implement what were judged by some as gratuitous changes from the
status quo.
Pitman wishes some of the other proposals were economically feasible to
pursue but reluctantly agrees that maintaining (and clearly documenting)
the status quo is probably the most reasonable avenue left to us.
∂15-Mar-89 0622 X3J13-mailer BASE-CHARACTER
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 06:22:19 PST
Received: from Semillon.ms by ArpaGateway.ms ; 15 MAR 89 06:09:24 PST
Date: 15 Mar 89 06:07 PST
From: masinter.pa@Xerox.COM
Subject: BASE-CHARACTER
To: CL-Characters@SAIL.STANFORD.EDU
cc: X3J13@SAIL.STANFORD.EDU
Message-ID: <890315-060924-3563@Xerox>
There were a couple of points that were only tersly alluded to in my note
on the character proposal.
BASE-CHARACTER
I think most of the confusions and problems with BASE-CHARACTER in the
proposal result from its definition in terms of the 'natural' encoding of
an implementation.
I think defining BASE-CHARACTER exactly as
(UPGRADED-ARRAY-ELEMENT-TYPE 'STANDARD-CHAR)
has all of the right properties. (Recall that UPGRADED-ARRAY-ELEMENT-TYPE
was added by the (passed) proposal in ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS.)
This definition is unambiguous and shows the relationship between the
string encoding and array upgrading strategies of the implementation and
the important character types. It ensures STANDARD-CHAR is a subtype of
BASE-CHARACTER.
Whether a character is "base" really only depends on the way that an
implementation represents strings, and not any other properties of the
implementation or the host operating system. Imagine two implementations on
a Unix machine, one of which encodes all strings as 16-bit characters, and
another which has two kinds of strings: 8-bit strings and 16-bit strings.
In the first implementation, the BASE-CHARACTER is CHARACTER: there's only
one kind of string. In the second implementation, the BASE-CHARACTER would
be those that could be stored in an 8-bit string, and it would be a proper
sub-type of CHARACTER.
To make this change requires leaving STANDARD-CHAR in the standard and then
merely defining BASE-CHARACTER in terms of it. Clearly BASE-STRING, if such
a name is necessary, would then just be a shorthand for (VECTOR
BASE-CHARACTER) with all the semantics implied by the array-element-type
proposals.
∂15-Mar-89 0636 X3J13-mailer Issue IN-PACKAGE-FUNCTIONALITY (Version 8)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 06:35:51 PST
Received: from Semillon.ms by ArpaGateway.ms ; 15 MAR 89 06:27:41 PST
Date: 15 Mar 89 06:27 PST
From: masinter.pa@Xerox.COM
Subject: Issue IN-PACKAGE-FUNCTIONALITY (Version 8)
To: X3J13@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
line-fold: NO
Message-ID: <890315-062741-3597@Xerox>
Version 4 of this issue (with only a version of
the SELECT-ONLY proposal) was discussed and tabled
at the last meeting.
This version includes two proposals; NEW-MACRO
(favored by many members of the cleanup committee)
and a new version of SELECT-ONLY.
!
Issue: IN-PACKAGE-FUNCTIONALITY
References: IN-PACKAGE (p182-183)
Category: CHANGE
Edit history: 07-Jul-88, Version 1 by Pitman
7-Oct-88, Version 2 by Masinter (discussion)
8-Dec-88, Version 3 by Masinter
12-Dec-88, Version 4 by Masinter
20-Jan-89, Version 5 by Loosemore
30-Jan-89, Version 6 by Loosemore
10-Mar-89, Version 7 by Loosemore
15-Mar-89, Version 8 by Masinter
(add back SELECT-ONLY)
Related-Issues: DEFPACKAGE (passed)
COMPILE-FILE-SYMBOL-HANDLING
Problem Description:
There are two typical uses for IN-PACKAGE -- to define/create a package
and to select a package. The fact that these two purposes have been
given to the same function has led to reduced error checking.
A more general problem is that the "Put In Seven Extremely Randoms"
convention described in CLtL is now recognized by many people as being
unsatisfactory for both package definition and package selection.
The DEFPACKAGE macro provides a much cleaner mechanism for package
definition, but there is still a need for a convenient way to select
a package that has well-defined compilation semantics.
Proposal (IN-PACKAGE-FUNCTIONALITY:NEW-MACRO):
Add a new macro:
SELECT-PACKAGE name [macro]
This macro causes *PACKAGE* to be set to the package named NAME,
which must be a symbol or string. An error is signalled if the
package does not already exist. Everything this macro does is also
performed at compile time if the call appears at top-level.
Remove the function IN-PACKAGE from the standard.
Remove the second paragraph of section 11.7 in CLtL. (This includes
the requirement for special compile-time treatment of the various
package functions.)
Rationale:
This could allow improved error checking and modularity, with only
minimal loss of functionality.
The rationale for proposing SELECT-PACKAGE as a replacement for
IN-PACKAGE, rather than simply changing IN-PACKAGE to have this
behavior, is that such an incompatible change would be confusing to
many people, and would make it more difficult to detect obsolete
usages. There is nothing in this proposal that would prevent
implementations from continuing to provide IN-PACKAGE as an extension.
Making SELECT-PACKAGE a macro rather than a function means that there
is no need to require COMPILE-FILE to handle it specially. Since
DEFPACKAGE is also defined to side-effect the compilation environment,
there is no need to require any of the package functions to be treated
specially by the compiler.
The language in section 11.7 of CLtL puts the burden on
implementations of ensuring that all symbols in a file which is
compiled and loaded end up in the same package that they would if the
source file were loaded interpretively. No implementation can
possibly meet this requirement because, in general, the runtime
behavior of the program cannot be predicted by the compiler.
Current Practice:
Probably no one implements this behavior exactly since it's an
incompatible change to CLtL.
Cost to Implementors:
The SELECT-PACKAGE macro can be implemented trivially by using
EVAL-WHEN in its expansion:
(defmacro select-package (name)
`(eval-when (eval compile load)
(setq *package*
(or (find-package ',name)
(error "Package ~s does not exist." ',name)))))
The changes required to COMPILE-FILE to remove the magic treatment
of the package functions are also likely to be small.
Cost to Users:
In most cases, minor syntactic changes to some files would be
necessary. Programmers that are now using the "Put In Seven
Extremely Randoms" convention will probably find it straightforward
to convert their code to do a DEFPACKAGE followed by a
SELECT-PACKAGE.
Cost of Non-Adoption:
The specification of COMPILE-FILE will be much more difficult to
understand.
The standard will require compilers to solve the halting problem.
Benefits:
Modular package declarations would be encouraged and errors due
to demand-creation of packages would be easier to detect.
The specification of COMPILE-FILE will be simplified.
There will be a clear statement of the requirements for program
conformance, as relating to usage of packages.
Aesthetics:
The fact that IN-PACKAGE is currently ambiguous about intent (whether
the package should exist already or not) is clearly not aesthetic.
Removing it can't be any worse.
The fact that the currently stated requirements for handling of
the package functions by the compiler are not implementable is
clearly not aesthetic.
!
Proposal (IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY):
Eliminate the ability of IN-PACKAGE to create a package on demand.
Eliminate the :NICKNAMES and :USE arguments to IN-PACKAGE, since they
are no longer needed.
The results of calling IN-PACKAGE if the package does not already
exist are implementation dependent; implementations "should signal"
an error, or otherwise provide the user with a way to recover from
the situation.
Examples:
#1: (IN-PACKAGE 'NO-SUCH-PACKAGE) ;would signal an error
#2: (DEFPACKAGE FOO ...options...) ;defines/creates a package
(IN-PACKAGE 'FOO) ;selects an existing package
Rationale:
This could allow improved error checking and modularity, with only
minimal loss of functionality.
Current Practice:
Probably no one implements this behavior since it's in direct
contradiction of both the definitions and numerous examples in CLtL.
Cost to Implementors:
As written, no change to implementations is required, but many will
want to make IN-PACKAGE signal an error. This change would be
straightforward to implement. The cost may not be trivial in all
cases, but should not be very large.
Cost to Users:
In most cases, minor syntactic changes to some files would be
necessary.
In some cases, no changes would be necessary since files may
already be doing IN-PACKAGE in situations where the author is
hoping he's made sure the real package declaration is already
loaded.
Cost of Non-Adoption:
Reduced error checking.
Less modular code.
Benefits:
Errors due to demand-creation of a package by IN-PACKAGE without
appropriate uses of the :USE or :NICKNAMES or without appropriate
calls to EXPORT, etc. afterward would be easier to detect.
Modular package declarations would be encouraged.
Aesthetics:
The fact that IN-PACKAGE is currently ambiguous about intent (whether
the package should exist already or not) is clearly not aesthetic.
Some people feel this change would be an aesthetic improvement.
Others feel that an incompatible change to IN-PACKAGE would merely
be confusing.
!
Discussion:
The dual use of IN-PACKAGE has not been helpful and is confusing.
Some people may find proposal NEW-MACRO more palatable if it merely
deprecated IN-PACKAGE, instead of removing it entirely.
Loosemore and Moon support proposal IN-PACKAGE-FUNCTIONALITY:NEW-MACRO.
Pitman says:
I support NEW-MACRO, though would really prefer you change "remove" to
"deprecate". Making this an incompatible change is gratuitous.
∂15-Mar-89 0912 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU candidates
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Mar 89 09:12:21 PST
Received: from Tenaya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 15 Mar 89 09:08:31-PST
Received: by Tenaya.Stanford.EDU (NeXT-0.8/NeXT-0.8)
id AA08580; Wed, 15 Mar 89 09:05:51 PST
Date: Wed, 15 Mar 89 09:05:51 PST
From: nilsson@tenaya.Stanford.EDU (Nils Nilsson)
Message-Id: <8903151705.AA08580@Tenaya.Stanford.EDU>
To: faculty@score.Stanford.EDU
Subject: candidates
Cc: nilsson@Tenaya.Stanford.EDU
At the faculty meeting yesterday, I was reminded of
the need for search committee chairs to publicize
talks by candidates. We have been interviewing various
people lately, and it would be helpful if the entire
CS/CSL faculty were informed of visits and talks
by candidates. So, please, in addition to sending
announcements out to the search committee and to
people in your own specialty areas, also send
to "faculty@score." Thanks, -Nils
∂15-Mar-89 0929 @Score.Stanford.EDU:jcm@ra.stanford.edu efficient use of computers
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Mar 89 09:29:45 PST
Received: from ra.stanford.edu by SCORE.STANFORD.EDU with TCP; Wed 15 Mar 89 09:26:42-PST
Received: by ra.stanford.edu (5.59/25-eef) id AA09562; Tue, 14 Mar 89 20:48:12 PDT
Date: Tue, 14 Mar 89 20:48:12 PDT
From: John Mitchell <jcm@ra.stanford.edu>
Message-Id: <8903150448.AA09562@ra.stanford.edu>
To: faculty@score
Subject: efficient use of computers
Reflecting on Dertouzos' talk, I'm not sure that we use
computers effeciently in this department. For example,
it would be useful to have an easy way to see how much
grant money I have spent this year, and how much is left
in each budgeted category. This must be on-line somewhere,
but I only get paper copy, which is in my office, and I
am at home.
∂15-Mar-89 0924 CL-Characters-mailer BASE-CHARACTER
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89 09:24:27 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557489; Wed 15-Mar-89 12:22:00 EST
Date: Wed, 15 Mar 89 12:22 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: BASE-CHARACTER
To: CL-Characters@SAIL.STANFORD.EDU
cc: X3J13@SAIL.STANFORD.EDU
In-Reply-To: <890315-060924-3563@Xerox>
Message-ID: <19890315172201.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
After thinking it over, I agree with Larry Masinter's comments
in the referenced message and the suggestion to define BASE-CHARACTER
as (UPGRADED-ARRAY-ELEMENT-TYPE 'STANDARD-CHAR).
∂15-Mar-89 0948 X3J13-mailer Issue: GENSYM-NAME-STICKINESS (Version 1)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 09:48:17 PST
Received: from fafnir.think.com by Think.COM; Wed, 15 Mar 89 12:44:45 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 15 Mar 89 12:46:05 EST
Received: by verdi.think.com; Wed, 15 Mar 89 12:42:51 EST
Date: Wed, 15 Mar 89 12:42:51 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903151742.AA02653@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Cc: x3j13@sail.stanford.edu
In-Reply-To: masinter.pa@xerox.com's message of 14 Mar 89 14:56 PST <890314-145716-2049@Xerox>
Subject: Issue: GENSYM-NAME-STICKINESS (Version 1)
Does KMP intend that GENSYM not be sticky for an integer argument
as well? That is, there is no way to reset the counter?
--Guy
∂15-Mar-89 0936 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from Aquinas.Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 09:36:35 PST
Received: from OCCAM.THINK.COM by Aquinas.Think.COM via INTERNET with SMTP id 124413; 15 Mar 89 12:34:29 EST
Date: Wed, 15 Mar 89 12:34 EST
From: Barry Margolin <barmar@FAFNIR.THINK.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
To: cl-cleanup@sail.stanford.edu
cc: X3J13@sail.stanford.edu
In-Reply-To: <890315-051405-3472@Xerox>
Message-ID: <19890315173420.1.BARMAR@OCCAM.THINK.COM>
Date: 15 Mar 89 05:13 PST
From: masinter.pa@xerox.com
Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE:CLARIFY):
Hooray! We finally got our collective acts together on this one!
barmar
∂15-Mar-89 1016 X3J13-mailer Issue: EXTRA-RETURN-VALUES (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89 10:16:01 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557537; Wed 15-Mar-89 13:12:57 EST
Date: Wed, 15 Mar 89 13:12 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXTRA-RETURN-VALUES (Version 2)
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu
In-Reply-To: <8902242235.AA14585@decwrl.dec.com>
Message-ID: <19890315181252.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
This one took longer than the others to answer because it is
a more difficult issue.
Date: 24 Feb 89 17:35
From: chapman%aitg.DEC@decwrl.dec.com
Problem: Is it OK to return extra values from Common Lisp functions?
Proposal: EXTRA-RETURN-VALUES:NO
Unless it is explicitly allowed in the standard,
if a standard function
returns a different number of return values from the number
specified by the standard, the results are unspecified.
I see a couple of problems with this. First, it is bootless to
prohibit extra return values without also forbidding returning
fewer values than specified. For example, when SUBTYPEP returns
NIL NIL, both NILs must actually be returned, not defaulted.
Second, I don't understand how "the results are unspecified" can be
correct here. First of all, that term doesn't appear in the error
terminology, and I don't know whether you meant "the return values are
unspecified" or "the consequences are unspecified". But I don't see
how you could mean either of those, since in fact what happens when
a certain number of values is returned is fully specified by the
language, and there is neither ambiguity nor implementation freedom.
If we look at the Rationale:
The reason is that
additional arguments are visible to otherwise portable programs. "For
instance, (multiple-value-call #'cons (floor x y)) looks portable, but it
will try to pass the wrong number of arguments to CONS if FLOOR returns an
extra value."
I think what you must have actually meant to propose is: Functions
specified in the standard must return exactly the number of values
specified in the standard, no more and no fewer. You could phrase this
as a requirement on implementations or as something that a conforming
program is permitted to assume, I don't much care which.
I found 21 functions in the LISP package in Symbolics Genera 7.4 that
return multiple values. Is this the correct number? Just as it was
useful to know that there are exactly 775 symbols in the LISP package
(in CLtL Common Lisp), it would be a useful check to publish the number
of functions that are supposed to return more than one value, and also
the number that are supposed to return no values.
I found two functions that return a different number of values than
CLtL specifies. GETHASH returns a third value, the key it found,
to go with the value it found (this might not be EQL to the argument
when the test is EQUAL or EQUALP). READ-LINE returns two additional
values, the delimiter character and the input-editor argument given
to the delimiter character. The first of these is a useful feature
that Common Lisp ought to have, the second is a necessary extension
for our environment that is not obviously useful in other environments.
After making and thinking about that assessment, my feeling is that I
would vote for this proposal if it was reworded in a way that I could
understand (which might or might not be what I suggested above) and if a
few specific functions (list to be supplied later) were specified to
allow additional values. I think this list would include all of the I/O
functions and would not include any of the arithmetic functions. I
haven't yet consulted with anyone else at Symbolics on this opinion,
though.
∂15-Mar-89 1018 X3J13-mailer BASE-CHARACTER
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 10:17:14 PST
Received: from fafnir.think.com by Think.COM; Wed, 15 Mar 89 13:13:21 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 15 Mar 89 13:14:40 EST
Received: by verdi.think.com; Wed, 15 Mar 89 13:11:29 EST
Date: Wed, 15 Mar 89 13:11:29 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903151811.AA02727@verdi.think.com>
To: CL-Characters@sail.stanford.edu
Cc: X3J13@sail.stanford.edu
Subject: BASE-CHARACTER
Larry's suggestion about defining BASE-CHARACTER to be simply
(UPGRADED-ARRAY-ELEMENT-TYPE 'STANDARD-CHAR) has a great deal
of charm, and I don't see anything wrong about it.
So I support it.
--Guy
∂15-Mar-89 1026 STAGER@Score.Stanford.EDU Grade Sheets
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Mar 89 10:26:24 PST
Date: Wed 15 Mar 89 10:22:26-PST
From: Claire Stager <STAGER@Score.Stanford.EDU>
Subject: Grade Sheets
To: faculty@Score.Stanford.EDU
cc: stager@Score.Stanford.EDU
Office: CS-TAC 29, 723-6094
Message-ID: <12478255093.12.STAGER@Score.Stanford.EDU>
The end-quarter grade sheets have arrived and will be delivered by courier
to your box today or tomorrow.
Please return them to Claire Stager in CS-TAC by ****MONDAY MARCH 27***.
Thank.
-------
∂15-Mar-89 1044 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU ICOT
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Mar 89 10:44:18 PST
Received: from Tenaya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 15 Mar 89 10:40:33-PST
Received: by Tenaya.Stanford.EDU (NeXT-0.8/NeXT-0.8)
id AA08672; Wed, 15 Mar 89 10:33:20 PST
Date: Wed, 15 Mar 89 10:33:20 PST
From: nilsson@Tenaya.Stanford.EDU (Nils Nilsson)
Message-Id: <8903151833.AA08672@Tenaya.Stanford.EDU>
To: faculty@score.Stanford.EDU
Subject: ICOT
Cc: nilsson@Tenaya.Stanford.EDU
FYI:
-------
Begin forwarded message:
To: cise.news@note.nsf.gov
Cc: bbarnes@note.nsf.gov
Subject: ICOT
From: "J. Mack Adams" <jadams@note.nsf.gov>
Dear Colleague:
I would like to call your attention to a special program we
have in the Computer and Information Science and Engineering
Directorate (CISE). The enclosed announcement describes the
National Science Foundation (NSF) and the Japanese Institute for
New Generation Computer Technology (ICOT) Visitors Program, which
support U. S. scientists and engineers to conduct research at
ICOT. In order to make it a more valuable experience, we have
modified the program.
The major modification is that we will now consider providing
research support for the visitor after his or her return from
Japan. Those who have a research grant in the same area of
research can apply for an extension to their grant. Those who
don't have a current grant can apply for research support for
up to two years after their return from Japan. Japanese language
training could be provided through the NSF International
Programs. Also, we have changed the eligibility criteria to
include advanced graduate students and post doctorates.
While ICOT has broad research interest, their current efforts
are focused in the following areas:
o AI Languages and Architectures
o Knowledge Representation and Machine Learning
o AI Applications
o Parallel Languages and their Semantics
o Software Science and Engineering
ICOT provides a unique cultural and research environment,
especially in areas closely related to the above.
If you have any interest in this program, please contact
your Program Director or Dr. Bruce Barnes at (202) 357-9572 or on
E-Mail on bbarnes@note.nsf.gov.
Sincerely,
William A. Wulf
Assistant Director
Directorate for Computer and
Information Science and Engineering
∂15-Mar-89 1051 @Score.Stanford.EDU:nilsson@Tenaya.Stanford.EDU possible faculty meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Mar 89 10:50:54 PST
Received: from Tenaya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 15 Mar 89 10:42:19-PST
Received: by Tenaya.Stanford.EDU (NeXT-0.8/NeXT-0.8)
id AA08687; Wed, 15 Mar 89 10:39:38 PST
Date: Wed, 15 Mar 89 10:39:38 PST
From: nilsson@tenaya.Stanford.EDU (Nils Nilsson)
Message-Id: <8903151839.AA08687@Tenaya.Stanford.EDU>
To: ac@score.Stanford.EDU
Subject: possible faculty meeting
Cc: nilsson@Tenaya.Stanford.EDU
Please reserve the time Tuesday, March 21,
2:30-4:00 for a possible faculty meeting. Whether or
not we have the meeting depends on progress I
make on offers to theory candidate(s) and whether
the theory committee has new suggestions or wants
additional guidance. If it happens, it will
be in mjh 146. Thanks, -Nils
∂15-Mar-89 1054 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Yesterday's Faculty Meeting
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Mar 89 10:54:42 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 15 Mar 89 10:46:25-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA11584; Wed, 15 Mar 89 10:46:19 -0800
Date: Wed, 15 Mar 1989 10:46:16 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: ac@score
Subject: Yesterday's Faculty Meeting
Message-Id: <CMM.0.87.605990776.chandler@polya.stanford.edu>
Someone left some papers in MJH-146 yesterday after the faculty meeting. One
was a paper "Languages under concatenation and shuffling (preliminary)) by
Steven T. Tschantz with a note on it to mail to Jay Gischer and initialled
"V". You can claim your papers in my office.
∂15-Mar-89 1131 GENESERETH@Score.Stanford.EDU Re: efficient use of computers
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Mar 89 11:31:08 PST
Date: Wed 15 Mar 89 11:15:19-PST
From: Mike Genesereth <GENESERETH@Score.Stanford.EDU>
Subject: Re: efficient use of computers
To: jcm@ra.Stanford.EDU
cc: faculty@Score.Stanford.EDU
In-Reply-To: <8903150448.AA09562@ra.stanford.edu>
Message-ID: <12478264718.37.GENESERETH@Score.Stanford.EDU>
John,
You may recall that about a year ago Arturs Keller and I proposed to
exploit computer power within our own setting more effectively (Faculty lunch
entitled "Overcomputerizing the Depraatment"). Since then, Artur has
chaired a committee that has selected an appropirate global database for the
department. Hopefuilly, once this is in place and the university databses
are coordinated, we can give you the service you request. I'd
be interested in hearing other suggestions you might have on how
we might use computers more effectively.
mrg
-------
∂15-Mar-89 1222 misha@polya.Stanford.EDU AFLB tomorrow!
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Mar 89 12:22:34 PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA06226; Wed, 15 Mar 89 12:19:25 -0800
Date: Wed, 15 Mar 89 12:19:25 -0800
From: Michael Kharitonov <misha@polya.Stanford.EDU>
Message-Id: <8903152019.AA06226@polya.Stanford.EDU>
To: aflb-all@polya.Stanford.EDU
Subject: AFLB tomorrow!
The last AFLB of this quarter is tomorrow, March 16, at 12:30 in room 352.
\title{Pseudo-random generation from one-way functions}
\author{Michael Luby\thanks{joint work with Russell Impagliazzo and
Leonid Levin} \\ International Computer Science Institute \\ Berkeley, California}
\date{}
\maketitle
\begin{abstract}
We show that the existence of one-way functions are necessary and sufficient
for the existence of pseudo-random generators in the following sense.
Let $f$ be an easily computable function such that when $x$ is chosen
randomly: (1) from $f(x)$ it is hard to recover an $x'$ with
$f(x')=f(x)$ by a small circuit, or; (2) $f$ has small degeneracy
and from $f(x)$ it is hard to recover $x$ by a fast algorithm.
>From one-way functions of type (1) or (2) we show how to construct
pseudo-random generators secure against small circuits or fast
algorithms, respectively, and vice-versa. Previous results show how
to construct pseudo-random generators from one-way functions that
have special properties ([Blum, Micali 82], [Yao 82], [Levin 85],
[Goldreich, Krawczyk, Luby 88]).
We use the results of [Goldreich, Levin 89] in a fundamental way.
\vspace{.1in}
\end{abstract}
\end{document}
∂15-Mar-89 1227 X3J13-mailer Re: Issue ERROR TERMINOLOGY, dpANS C
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 12:27:28 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
id AA14532; Wed, 15 Mar 89 12:27:45 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA13443; Wed, 15 Mar 89 12:23:50 PST
Received: by clam.sun.com (4.0/SMI-4.0)
id AA28038; Wed, 15 Mar 89 12:27:22 PST
Date: Wed, 15 Mar 89 12:27:22 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903152027.AA28038@clam.sun.com>
To: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
Subject: Re: Issue ERROR TERMINOLOGY, dpANS C
Cc: x3j13@sail.stanford.edu
Discussion continued on cl-editorial.
∂15-Mar-89 1342 HEMENWAY@Score.Stanford.EDU Peterson's Guide Information
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Mar 89 13:42:22 PST
Date: Wed 15 Mar 89 13:39:41-PST
From: Sharon Hemenway <HEMENWAY@Score.Stanford.EDU>
Subject: Peterson's Guide Information
To: ac@Score.Stanford.EDU
Reply-To: Hemenway@Score.Stanford.EDU
Message-ID: <12478290999.26.HEMENWAY@Score.Stanford.EDU>
This is just a reminder that I must have all revisions to the
Peterson's guide faculty research entries by this Friday, March 17.
(I put copies of this year's sheet in your mailboxes on March 3.) I
will be sending the revised copy to Peterson's on the 20th so if you
do want changes, I *must* have them by Friday.
Thanks,
Sharon
-------
∂15-Mar-89 1347 @Score.Stanford.EDU:chandler@polya.Stanford.EDU CSD Retreat
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Mar 89 13:47:34 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 15 Mar 89 13:43:06-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA12685; Wed, 15 Mar 89 13:43:02 -0800
Date: Wed, 15 Mar 1989 13:42:59 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score
Subject: CSD Retreat
Message-Id: <CMM.0.87.606001379.chandler@polya.stanford.edu>
On Friday the folks from Chaminade will call me and ask for a definite head
count. They will prepare a contract that we must sign in order to reserve
space for the retreat. We will be bound by this contract to pay for the
rooms which we reserve. I will use the information you have sent me to make
arrangements for our space requirement. If your situation has changed,
please let me know ASAP. If you asked for accommodations and then do not
attend, we will be charged anyway. If I have not heard from you, please let
me know if you plan to attend. Thanks for your help.
∂15-Mar-89 1414 aaai@sumex-aim.stanford.edu Symposium Meeting
Received: from sumex-aim.stanford.edu by SAIL.Stanford.EDU with TCP; 15 Mar 89 14:13:59 PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA18408; Wed, 15 Mar 89 14:11:20 PST
Date: Wed, 15 Mar 1989 14:11:20 PST
From: AAAI <aaai@sumex-aim.stanford.edu>
To: officers:;@sumex-aim.stanford.edu
Cc: aaai@sumex-aim.stanford.edu, bobrow.pa@xerox.com
Subject: Symposium Meeting
Message-Id: <CMM.0.88.606003080.aaai@sumex-aim.stanford.edu>
Hector and Peter would like to hold a breakfast meeting on Wednesday, March
29, at 7:30 am in the coffee shop at the Holiday Inn in Palo ALto to
review this year's symposium series.
If you can make the meeting, please inform me as soon as possible.
Claudia
∂15-Mar-89 1417 aaai@sumex-aim.stanford.edu Opps!
Received: from sumex-aim.stanford.edu by SAIL.Stanford.EDU with TCP; 15 Mar 89 14:14:47 PST
Received: by sumex-aim.stanford.edu (4.0/inc-1.0)
id AA18440; Wed, 15 Mar 89 14:12:24 PST
Date: Wed, 15 Mar 1989 14:12:23 PST
From: AAAI <aaai@sumex-aim.stanford.edu>
To: officers:;@sumex-aim.stanford.edu
Cc: aaai@sumex-aim.stanford.edu
Subject: Opps!
Message-Id: <CMM.0.88.606003143.aaai@sumex-aim.stanford.edu>
OPPS! Wrong .dis list!
Claudia
∂15-Mar-89 1446 X3J13-mailer Issue ERROR TERMINOLOGY
To: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
Is it the case that ``fatal'' is well-defined? If so, ``harmless'' is
simply something that is not fatal. According to my mathematics
education, that renders the term well-defined.
``Indeed, there is no way to invoke GC in Common Lisp and with a few
exceptions such as messages, GC must have NO side effects.''
Unsolicited messages can happen, and there is a proposal on the
cl-editorial table to render them harmless. If GC can have no side
effects, then why not state that and not wonder about unsolicited
messages? If we did that, then any Common Lisp that does print a
progress note is *out* of conformance.
Also, as I've said several times, rehashing, termination of processes,
progress messages, flushing IO buffers, closing streams, and a list of
possibly hundreds of things are side effects of GC that should be
guaranteed harmless (that is, not fatal).
``> Some things are not immediately harmful but may cause
> trouble later on.
Yes, lots of things are that way.''
The definition of fatal puts no time constraints on the fatality. Therefore,
neither does its negation.
``> By ``unpredictable but harmless'', I think we are in effect saying
> ``not completely unpredictable''. That is, we promise something but
> don't quite say what it is. For example, Lisp will presumably not
> break off and start playing chess. But maybe it's harmless to start
> playing chess.''
The beauty of a specification is knowing what not to say in order to
allow rational interpreters the freedom to interpret rationality now
and in the unpredictable future. There is considerable genius in the
fine line that Steele tread in CLtL on this. Does anyone rationally
think that a Common Lisp would be taken seriously that while GCing
broke out in a game of chess or an Irish gig? I refuse to seriously
debate with anyone who would use that as an example of something that
we must utter one word in the specification to prevent.
``As far as I can see, the only reasonable option is to specify
some range of possible consequences. The constraints, whatever
they may be, make it possible to reason about what the program
will do.''
The reason this won't easily work is that it presumes that we are able
to accurately predict future implementation techniques and even to
fully comprehend current ones. I'm sure that KMP or I could supply an
endless stream of new and bizarre cases that have to be explicitly
dealt with. (I single out KMP because he has uncanny creativity.)
But, I'll change the debate a little. I've claimed that ``harmless''
is well-defined if and only if ``fatal'' is well-defined or at least
defined well enough. So, to convince me that ``harmless'' should be
pitched, you must convince me that ``fatal'' must be pitched.
-rpg-
∂15-Mar-89 1451 CL-Compiler-mailer Issue SAFE-CODE, version 1
To: cl-compiler@SAIL.Stanford.EDU, x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
According to my understanding of the dictionary definitions,
``unsafe'' means primarily ``the opposite or reversal of `safe' '' and
secondarily ``not safe.'' This coincides with Moon's reading.
Therefore, I propose we use the term ``nonsafe'' which clearly means
``not safe.'' This, coupled with the already very explicit definition
of ``unsafe,'' which explains that unsafe code might actually be safe,
should take care of his objection.
-rpg-
∂15-Mar-89 1506 CL-Editorial-mailer Re: Issue ERROR TERMINOLOGY, dpANS C
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 15 Mar 89 15:06:13 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa11469; 15 Mar 89 19:24 GMT
Date: Wed, 15 Mar 89 19:21:20 GMT
Message-Id: <2039.8903151921@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue ERROR TERMINOLOGY, dpANS C
To: Cris Perdue <cperdue@sun.com>, chapman <@decwrl.dec.com:chapman@aitg.dec>
Cc: kempf <@sun.com:kempf@clam>, peck <@sun.com:peck@clam>,
sgadol <@sun.com:sgadol@clam>, x3j13@sail.stanford.edu,
cl-editorial@sail.stanford.edu, rpg <@sail.stanford.edu:rpg@lucid.com>
Perhaps this discussion should be in cl-editorial...
> From: Cris Perdue <cperdue@com.sun>
> The error terminology is OK, except for "consequences
> are unspecified". That concept is broken, though it
> has serious defenders. For example, Dick Gabriel says,
>
> "If we were to drop this term, then every time we are
> ``explicitly vague'' a valid possibility is that a fatal
> error can occur. How is it any better to say that what happens
> when some operation happens is ``explicitly vague''."
Perhaps the problem is that "harmless" is not very well defined.
Maybe we can convince ourselves that ``the consequences of the garbage
collector when invoked'' are harmless, but how many other examples can
we find? Some things are not immediately harmful but may cause
trouble later on. For example, are the consequences of using EQ to
compare numbers harmless? Suppose we know that a fatal error will not
immediately occur. Is that enough to make it harmless (in this case)?
[I know this is most likely to be a case where the ``return values are
unspecified'', but it was the best I could do on short notice, and we
can ask whether these consequences would be ``harmless'' even if they
wouldn't be described as such in the standard.]
By ``unpredictable but harmless'', I think we are in effect saying
``not completely unpredictable''. That is, we promise something but
don't quite say what it is. For example, Lisp will presumably not
break off and start playing chess. But maybe it's harmless to start
playing chess.
> A typical area of "explicit vagueness" is the destructive operations
> on lists. The explicit vagueness here is quite limited. For
> some operations any top level cell of certain lists may or may
> not be modified. Similar statements apply to other operations.
> The consequences are far from being unspecified but harmless.
> They are CONSTRAINED but meaningful.
This is an interesting example. First, there's the question ``the
consequences of what?'' The consequences of applying the destructive
operation? The consequences of doing anything that depends on whether
or not cells were modified? We really have to see how these phrases
are used in the actual description of a function.
Maybe what we want is this:
The result is a list with certain (specified) properties.
The side effects on cells in the argument list are unspecified.
In addition, there might be a general warning that the consequences of
depending on unspecified side effects are undefined.
In an earlier message, Cris Perdue said:
Let's pick a few actual examples where the language definition is
proposed to say "consequences are unspecified". (Go ahead, I
challenge you.) I think we will find that the description will
have to be more specific than that. It can make sense to say that
"effect X may or may not occur". It can make sense to say that
"data structure Y may be modified arbitrarily". If we can define a
set of effects that we consider harmless, and change "unpredictable
but harmless" to just "harmless", or some such, that could also
make sense, but not the current language.
I am not quite convinced by this argument. We have to be careful not
to make too much undefined. If we consider some operation, some
things may be specified, some things left open, and so on. The
description may have to be ``more specific'' in that we shouldn't
describe the whole thing as ``unspecified'' when we can instead say
something more precise; but that doesn't show that some parts of the
description cannot reasonably use ``unspecified'' or ``undefined''.
Besides, this argument applies just as well to ``undefined'' as it
does to ``unspecified'' -- there would be the same need to be more
specific. So again I suspect it is the ``harmless'' that is really at
fault.
Anyway, the draft C standard makes a somewhat different distinction
between ``unspecified'' and ``undefined''. In particular, correct
programs may have unspecified behavior; those with undefined behavior
are incorrect, or at least nonportable:
Unspecified behavior -- behavior, for a correct program construct
and correct data, for which the Standard imposes no requirements.
Undefined behavior -- behavior, upon use of a nonportable or
erroneous program construct, of erroneous data, or of
indeterminately-values objects, for which the Standard imposes no
requirements. Permissible undefined behavior ranges from ignoring
the situation completely with unpredictable results, to behaving
during translation or program execution in a documented manner
characteristic of the environment (with or without the issuance of a
diagnostic message), to terminating translation or execution (with
the issuance of a diagnostic message).
There is also a category of ``implementation-defined behavior".
An example: in a function call if the argument types or the number of
arguments are wrong [this is said more precisely in the standard]
``the behavior is undefined''. However: ``The order of evaluation of
the function designator, the arguments, and subexpressions within the
arguments is unspecified, but there is a sequence point before the
actual call."
The Rationale (a separate document) says:
The terms unspecified behavior, undefined behavior, and
implementation-defined behavior are used to categorize the result of
writing programs whose properties the Standard does not, or cannot,
completely describe. The goal of adopting this categorization is to
allow a certain variety among implementations which permits quality
of implementation to be an active force in the marketplace, as well
as to allow certain popular extensions, without removing the cachet
of conformance to the standard. An appendix to the standard, A.6,
catalogs those behaviors that fall into one of these three
categories.
Unspecified behavior gives the implementor some latitude in
translating programs. This latitude does not extend so far as
failing to translate the program.
Undefined behavior gives the implementor license not to catch
certain program errors that are difficult to diagnose. It also
identifies areas of possible conforming language extension: the
implementor may augment the language by providing a definition of
the officially undefined behavior.
From all this I conclude that we probably do need both unspecified and
undefined. However, it is unclear exactly what distinction they
should express.
[The C standard also distinguishes between strictly conforming [more or
less: portable] programs and conforming programs.]
-- Jeff
∂15-Mar-89 1553 X3J13-mailer Re: Issue: EXTRA-RETURN-VALUES
Received: from ti.com by SAIL.Stanford.EDU with TCP; 15 Mar 89 15:52:37 PST
Received: by ti.com id AA13974; Wed, 15 Mar 89 15:08:09 CST
Received: from Kelvin by tilde id AA23610; Tue, 14 Mar 89 11:36:42 CST
Message-Id: <2814888931-7906489@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Tue, 14 Mar 89 11:35:31 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: chapman%aitg.DEC@decwrl.dec.com
Cc: x3j13@sail.stanford.edu
Subject: Re: Issue: EXTRA-RETURN-VALUES
In-Reply-To: Msg of 24 Feb 89 17:35 from chapman%aitg.DEC@decwrl.dec.com
> Proposal: EXTRA-RETURN-VALUES:NO
> Unless it is explicitly allowed in the standard,
> if a standard function
> returns a different number of return values from the number
> specified by the standard, the results are unspecified.
>
>
> Rationale:
>
> The reason is that
> additional arguments are visible to otherwise portable programs. "For
> instance, (multiple-value-call #'cons (floor x y)) looks portable, but it
> will try to pass the wrong number of arguments to CONS if FLOOR returns an
> extra value."
This may be a bit of over-kill. I suggest making this restriction only
for functions which the standard specifies as returning multiple values.
For functions that the standard says return one value, there would be no
reason for a portable program to go out of its way to accept more than
one value from them, so additional values shouldn't hurt.
Also, "the results are unspecified" doesn't seem to be the right
terminology to use here since this is intended to be a restriction on
the implementation. How about:
Unless it is explicitly allowed in the standard, functions which are
specified to return other than one value may not be extended by
implementations to return more values than specified.
∂15-Mar-89 1603 X3J13-mailer Feb. 21 letter ballot
Received: from ti.com by SAIL.Stanford.EDU with TCP; 15 Mar 89 16:00:39 PST
Received: by ti.com id AA14034; Wed, 15 Mar 89 15:09:30 CST
Received: from home by tilde id AA26164; Tue, 14 Mar 89 13:07:13 CST
Received: by home id AA15845; Tue, 14 Mar 89 13:07:05 CST
Date: Tue, 14 Mar 89 13:07:05 CST
From: David Bartley <bartley@home.csc.ti.com>
Message-Id: <8903141907.AA15845@home>
To: x3j13@sail.stanford.edu
Subject: Feb. 21 letter ballot
Reply-To: Bartley@ti-csl.csc.ti.com
This is TI's vote on the Feb. 21 letter ballot:
________________________________________________________________________
Issue or section name | Version | Y | I | A |
------------------------------------------------------------------------
CUT-OFF-DATES | 4 | Y | | |
------------------------------------------------------------------------
ERROR-TERMINOLOGY | 5 | | I | |
------------------------------------------------------------------------
FONTS | 2 | Y | | |
------------------------------------------------------------------------
TOC | 1 | Y | | |
------------------------------------------------------------------------
Section 1.8 | 5.8 | | I | |
------------------------------------------------------------------------
Section 2.3 | 5.8 | | I | |
------------------------------------------------------------------------
Section 2.4 | 5.8 | Y | | |
------------------------------------------------------------------------
Section 2.5 | 5.8 | Y | | |
------------------------------------------------------------------------
Section 6.1 | 5.8 | Y | | |
------------------------------------------------------------------------
Concerning ERROR-TERMINOLOGY: We understand that this section is
undergoing a significant rewrite.
(By the way, in the definition of CONFORMING CODE, shouldn't there be
a third point saying that conforming code does not depend on the
results of any "undefined" or "unspecified" situations?)
Concerning Section 1.8: This writeup is too terse to be very meaningful
---it looks like a preliminary outline instead of a final draft.
Concerning Section 2.3: Page 2-13 of the draft concerns David Gray
because it does not include any of the classes from page 1-17 of
88-002R. Why did we go through all that hassle of redefining the
FUNCTION type if it is not going to be defined here as a class?
Shouldn't all of the classes on page 1-17 be included?
--db--
∂15-Mar-89 1722 X3J13-mailer Bartley's Comments
To: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
David writes:
``(By the way, in the definition of CONFORMING CODE, shouldn't there be
a third point saying that conforming code does not depend on the
results of any "undefined" or "unspecified" situations?)''
The descriptions of unspecified and undefined already state exactly this.
Do you think it should be repeated in the definition of conforming code?
-rpg-
∂15-Mar-89 1747 @polya.Stanford.EDU:tah@linz MTC Seminar
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Mar 89 17:46:57 PST
Received: from [36.8.0.142] by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA01761; Wed, 15 Mar 89 17:43:35 -0800
Received: by linz.stanford.edu (5.59/25-eef) id AA00292; Wed, 15 Mar 89 17:43:27 PDT
Message-Id: <8903160143.AA00292@linz.stanford.edu>
To: lop@polya, csd@score
Subject: MTC Seminar
Date: 15 Mar 89 17:43:24 PST (Wed)
From: Tom Henzinger <tah@linz>
Friday, March 17, 12 noon, MJH 301:
ALGEBRAIC OPERATIONAL SEMANTICS
Yuri Gurevich
University of Michigan, Stanford University and IBM
Abstract:
We distinguish between explaining a programming language $L$
(explaining, say, to somebody who wants to write a compiler for $L$)
and explaining programs in $L$. The first task is easier and may be
accomplished, in the case of sequential languages, by providing an
abstract machine M (a transition system). The second task is more
difficult and is done usually by induction; the denotation $[P_1;P_2]$
of the concatenation of programs $P_1$, $P_2$ may be the composition of
the denotations $[P_1]$, $[P_2]$, etc. To convince yourself that the
first task is indeed easier, you may think about gotos.
However, the easier task is not that easy. What are states of $M$,
what are transition rules, how much can be accomplished in one step,
can one get away with just one machine or there is a need to consider
a family of machines, should one represent resources and if yes then
how, etc.? In our approach, a state is what an algebraist may call a
many-sorted algebra and a logician would call a many-sorted
first-order structure. Surprisingly, a very restrictive and simple
syntax of transition rules allows modeling of involved, full-scale,
real-life languages like Modula-2.
Distributed computing is a challenge to the naive approach of
transition systems. To explain a language like Occam in an honest and
undistorted way, one is forced to admit that sometimes the model does
not have a global state. But the challenge can be met.
In the talk we will illustrate the approach on examples of sequential
and -- if time permits -- distributed nature.
∂15-Mar-89 1756 X3J13-mailer Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 17:56:25 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAR 89 17:17:14 PST
Date: 15 Mar 89 17:16 PST
From: masinter.pa@Xerox.COM
Subject: Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)
To: x3J13@sail.stanford.edu
line-fold: NO
reply-to: CL-CLEANUP@Sail.stanford.edu
Message-ID: <890315-171714-1269@Xerox>
!
Issue: BREAK-ON-WARNINGS-OBSOLETE
Forum: Cleanup
References: *BREAK-ON-WARNINGS* (CLtL p432, CL Condition System p40)
*BREAK-ON-SIGNALS* (CL Condition System p25)
Category: CLARIFICATION/CHANGE
Edit history: 07-Mar-89, Version 1 by Pitman
Problem Description:
With the advent of *BREAK-ON-SIGNALS*, *BREAK-ON-WARNINGS* is
redundant and unnecessary.
Proposal (BREAK-ON-WARNINGS-OBSOLETE:DEPRECATE):
Deprecate *BREAK-ON-WARNINGS*.
Test Case:
N/A
Rationale:
This will lead to simplification of the description of WARN.
Not only are the two variables overkill, but they have an effect
in an identifiably but uselessly distinct place.
Current Practice:
Since deprecation is not removal, presumably everyone who conforms
is compatible.
Cost to Implementors:
Since the feature is deprecated rather than flushed: none.
Cost to Users:
Since the feature is deprecated rather than flushed: none.
Users should get used to writing (SETQ *BREAK-ON-SIGNALS* 'WARNING)
rather than (SETQ *BREAK-ON-WARNINGS* T).
Cost of Non-Adoption:
The definition of WARN will be gratuitously cluttered.
Benefits:
Cost of non-adoption is avoided.
Aesthetics:
Slight improvement.
Discussion:
Pitman thinks this is a good idea, but doesn't think a lot of time
should be wasted discussing the issue if there is strong opposition.
∂15-Mar-89 1814 @polya.Stanford.EDU:goldberg@Jinn.stanford.edu Interior study group
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Mar 89 18:14:04 PST
Received: from Jinn.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA03325; Wed, 15 Mar 89 18:11:31 -0800
Received: by Jinn.stanford.edu (4.0/25-eef) id AA23513; Wed, 15 Mar 89 18:11:44 PST
Date: Wed, 15 Mar 89 18:11:44 PST
From: Andrew Goldberg <goldberg@Jinn.stanford.edu>
Message-Id: <8903160211.AA23513@Jinn.stanford.edu>
To: aflb-su@polya
Subject: Interior study group
Next quarter I would like to organize a group to study interior-point
methods for linear programming, which are the most exciting recent
developments in the area. This will be a very informal group, every
member of which will be expected to contribute by presenting results
from the literature (possibly in cooperation with another group member).
The group will be meeting once a week. Participants are expected to know
elementary linear programming, such as the duality theorem and the
simplex method. We will study Karmarkar- and Renegar- type algorithms,
and selected topics from linear programming which are needed for the
understanding of these methods.
Please let me know if you would like to participate. Feel free to contact
me if you have any questions.
Although I am not sure about the time yet, I would like to keep the length
of each meeting flexible. To do this, I suggest to start around 4:30, and
maybe have take-out food to make prevent people from leaving for diner.
Is it a good idea?
--Andy
∂15-Mar-89 1853 X3J13-mailer Re: Issue: EXTRA-RETURN-VALUES
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 15 Mar 89 18:53:34 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA03073; Wed, 15 Mar 89 17:50:24 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA04907; Wed, 15 Mar 89 17:50:16 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903160050.AA04907@defun.utah.edu>
Date: Wed, 15 Mar 89 17:50:14 MST
Subject: Re: Issue: EXTRA-RETURN-VALUES
To: David N Gray <Gray@DSG.csc.ti.com>
Cc: chapman%aitg.DEC@decwrl.dec.com, x3j13@sail.stanford.edu
In-Reply-To: David N Gray <Gray@DSG.csc.ti.com>, Tue, 14 Mar 89 11:35:31 CST
> Date: Tue, 14 Mar 89 11:35:31 CST
> From: David N Gray <Gray@DSG.csc.ti.com>
>
> This may be a bit of over-kill. I suggest making this restriction only
> for functions which the standard specifies as returning multiple values.
> For functions that the standard says return one value, there would be no
> reason for a portable program to go out of its way to accept more than
> one value from them, so additional values shouldn't hurt.
I disagree. I've been known to use an idiom like
(multiple-value-call #'foo (fn1) (fn2))
where FN1 is a standard Common Lisp function which is supposed to return
one value, and FN2 is a function that returns multiple values. If FN1
is allowed to return extra values, this won't work.
-Sandra
-------
∂15-Mar-89 1941 CL-Compiler-mailer issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 15 Mar 89 19:40:55 PST
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88);
Wed, 15 Mar 89 21:39:48 CST id AA08835 for cl-compiler@sail.stanford.edu
Posted-Date: Wed, 15 Mar 89 21:38:06 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
id AA16529; Wed, 15 Mar 89 21:38:06 CST
Date: Wed, 15 Mar 89 21:38:06 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8903160338.AA16529@pavo.src.honeywell.com>
To: cl-compiler@sail.stanford.edu
Cc: x3j13@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 13 Mar 89 15:50:07 -0700 <8903132250.AA02499@defun.utah.edu>
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
If we permit the compiler to signal warnings for functions where the
compile-time environment signature is different from the function call
being compiled, why do we prohibit it for generic functions?
From COMPILE-ENVIRONMENT-CONSISTENCY:
(3) The compiler *must not* make any additional assumptions about
consistency between the compiletime and runtime environments. In
particular:
(a) The compiler may not ... It is, however,
permissible for the compiler to emit warning messages when
compiling calls to functions that are defined in the compiletime
environment, but where the wrong number or type of arguments
are supplied.
But then in CLOS-MACRO-COMPILATION:
DEFMETHOD:
* The method is not callable at compile-time. If there is a generic
function with the same name at compile-time, compiling a DEFMETHOD
will not add the method to that generic function. The compiler may
perform tests for lambda-list congruence only between the DEFGENERICs
and DEFMETHODs for a given generic function name that appear within
the file being compiled, and not against a generic function of the
same name which exists in the compile-time environment.
∂15-Mar-89 2041 @Score.Stanford.EDU:jlh@vsop.Stanford.EDU Re: efficient use of computers
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Mar 89 20:41:22 PST
Received: from vsop.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 15 Mar 89 20:37:50-PST
Received: by vsop.Stanford.EDU (5.57/Ultrix2.4-C)
id AA28411; Wed, 15 Mar 89 20:34:07 PST
Message-Id: <8903160434.AA28411@vsop.Stanford.EDU>
To: Mike Genesereth <GENESERETH@score.stanford.edu>
Cc: jcm@ra.stanford.edu, faculty@score.stanford.edu, jlh@vsop.Stanford.EDU
Subject: Re: efficient use of computers
In-Reply-To: Your message of Wed, 15 Mar 89 11:15:19 -0800.
<12478264718.37.GENESERETH@Score.Stanford.EDU>
Date: Wed, 15 Mar 89 20:34:01 PST
From: jlh@vsop.Stanford.EDU
We currently download budget information from the university databases
directly into our projection spreadsheets.
John
∂15-Mar-89 2152 @Score.Stanford.EDU:wheaton@Athena.Stanford.EDU efficient use of computers
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Mar 89 21:52:47 PST
Received: from Athena.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Wed 15 Mar 89 21:49:30-PST
Received: by Athena.Stanford.EDU (5.61/25-eef) id AA00224; Wed, 15 Mar 89 21:47:37 -0800
Date: Wed, 15 Mar 89 21:47:37 -0800
From: George S Wheaton <wheaton@Athena.Stanford.EDU>
Message-Id: <8903160547.AA00224@Athena.Stanford.EDU>
To: jlh@vsop.Stanford.EDU
Cc: GENESERETH@score.Stanford.EDU, jcm@ra.Stanford.EDU,
faculty@score.Stanford.EDU, jlh@vsop.Stanford.EDU
In-Reply-To: jlh@vsop.Stanford.EDU's message of Wed, 15 Mar 89 20:34:01 PST <8903160434.AA28411@vsop.Stanford.EDU>
Subject: efficient use of computers
The SU financial system is flexible enough so you can design your own
format for downloading. I use the same system for departmental
budget/actual comparisons and dump the data into a "custom" Excel
spreadsheet.
gw
∂16-Mar-89 0601 X3J13-mailer Re: issue COMPILER-VERBOSITY, version 6
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 06:01:53 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 05:48:37 PST
Date: 16 Mar 89 05:47 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue COMPILER-VERBOSITY, version 6
To: cl-compiler@sail.stanford.edu
cc: x3J13@sail.stanford.edu
Message-ID: <890316-054837-3596@Xerox>
The current practice of this proposal says that one implementation has a
:VERBOSE that is used for what this proposal calls :PRINT, gives no current
examples of :VERBOSE, etc. I'm suspicious of a proposal to add something
that is significantly more complex than what any current implementation
already has.
COMPILE-FILE is significantly more part of the "environment" than LOAD is,
and I think that the less we specify its behavior, the better off we are.
While there are useful programmatic portable invocations of LOAD where
controlling the output behavior portably is important, the case for
portable control of output behavior of COMPILE-FILE is much less strong.
What about environments that support incremental compilation? Where
compilation is handled by a background process? Wouldn't this be
unnecessary junk for them to add?
If we have some doubts about whether some of these 'puppies' are really
useful, shouldn't we leave them behind? Not require them?
Larry
∂16-Mar-89 0632 X3J13-mailer Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 06:32:40 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 06:23:30 PST
Date: 16 Mar 89 06:22 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Tue, 14 Mar 89 20:27 EST
To: cl-compiler@sail.stanford.edu
cc: X3J13@sail.stanford.edu
Message-ID: <890316-062330-3633@Xerox>
I think the previous sentiment was more strongly toward removing
COMPILED-FUNCTION rather than tightening its definition. However, in the
heat of the FUNCTION-TYPE discussion, this seemed to be a controversial
backward incompatibility (why not just leave it in, but leave it
unspecified?)
I've extracted some quotes about COMPILED-FUNCTION from the CL-CLEANUP
discussion on FUNCTION-TYPE. Of course, these are taken out of context...
Return-Path: <@SAIL.STANFORD.EDU:Moon@STONY-BROOK.SCRC.Symbolics.COM>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 02 MAR 87 21:29:49 PST
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 2 Mar
87 21:27:23 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 82Date: Tue, 3
Mar 87 00:26 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: Tue, 3 Mar 87 00:26 EST
It might be wise to add LEXICAL-CLOSURE and INTERPRETED-FUNCTION data
types, to go along with the COMPILED-FUNCTION type that already exists.
These three would be disjoint subtypes of FUNCTION, but not necessarily
an exhaustive partition. There might be other ways to slice the space
of types, since it's not so clear what a function not inside a closure
is good for. Alternatively we could flush COMPILED-FUNCTION and say
that the subtypes of FUNCTION are all implementation-dependent. But I
think having COMPILED-FUNCTION without the others is weird.
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:FAHLMAN@C.CS.CMU.EDU>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 08 MAR 87 21:56:23 PST
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Mar 87
21:53:10 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 9 Mar 87 00:53:51-EST
Date: Mon, 9 Mar 87 00:53 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Probably we should explicitly name COMPILED-FUNCTION and
INTERPRETED-FUNCTION as subtypes of FUNCTION, and make TYPEP work for
them.
- - - - - - - - -
Return-Path: <RPG@SAIL.STANFORD.EDU>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 08 MAR 87 23:54:05 PST
Date: 08 Mar 87 23:51 PST
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Possibly these should not be required to be pairwise disjoint (?).
I think we shouldn't presume that all implementations implement
functions as closures. I can imagine an implementation with
COMPILED-FUNCTIONs, INTERPRETED-FUNCTIONs, COMPILED-CLOSUREs,
and INTERPRETED-CLOSUREs.
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:FAHLMAN@C.CS.CMU.EDU>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 09 MAR 87 08:07:46 PST
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Mar 87
08:01:49 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 9 Mar 87 10:57:49-EST
Date: Mon, 9 Mar 87 10:57 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Well, these make sense only in systems that do support both compiled and
interpreted code. In compiler-only or interpreter-only systems, I guess
the best move would be to say that every function is a member of both of
these subtypes: it is both a fast function and a slow function.
Now you're the one who is letting the user see internal stuff that is
none of his concern. All of these functions are closures, in that they
no longer have any free variables waiting to be closed. In some cases,
there may have been none in the first place, and implementors may want
to use some efficient internal form in such cases, but is there any
reason the user needs to know that? A confusing concept that does him
no good (I think).
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:Moon@STONY-BROOK.SCRC.Symbolics.COM>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 10 MAR 87 07:54:56 PST
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Mar
87 07:48:09 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 89098; Tue
10-Mar-87 01:57:50 EST
Date: Tue, 10 Mar 87 01:57 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
... I vacillate between
saying that all of the subtypes of FUNCTION are implementation-dependent
and shouldn't be standardized (thus COMPILED-FUNCTION should be
removed), and saying that programs might want to know this information,
so all the plausible subtypes should have standard names, even if they
aren't distinct in some implementations. The only thing I feel strongly
and consistently about is that COMPILED-FUNCTION should not be the only
standardized subtype of FUNCTION; it should either acquire some siblings
or go away.
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:KMP@STONY-BROOK.SCRC.Symbolics.COM>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 13 MAY 87 00:13:57 PDT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 13 May
87 00:12:36 PDT
Received: from TSUKUBA.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM
via CHAOS with CHAOS-MAIL id 138655; Wed 13-May-87 03:10:55 EDT
Date: Wed, 13 May 87 03:10 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
* It seems to me that we might as well go ahead and create types
INTERPRETED-FUNCTION and COMPILED-FUNCTION since the combination of
the FUNCTION type and the COMPILED-FUNCTION-P predicate already
implements
this distinction. Perhaps eventually COMPILED-FUNCTION-P could be
flushed.
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:FAHLMAN@C.CS.CMU.EDU>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 17 MAY 87 19:32:45 PDT
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 May 87
19:31:22 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 17 May 87 22:30:44-EDT
Date: Sun, 17 May 87 22:30 EDT
Message-ID: <FAHLMAN.12303231779.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
One possibility is not to define any of these and to eliminate
COMPILED-FUNCTION-P. That's what I proposed in version 3. The other
possibility is to define COMPILED-FUNCTION and INTERPRETED-FUNCTION as
subtypes of FUNCTION, but then we have to spell out what happens in
implementations that have only one internal representation or that have
more than two -- raw interpreted, transformed, and fully compiled, for
example. Then there's the question of whether closures are, or can be,
a separate subtype. In some sense, all true functions are closures,
since to get one you close a lambda expression in some lexical
environment. However, we might want to reserve the word "closure" for
functions that actually capture some part of the lexical context outside
the function itself, and to create CLOSURE types based on this idea.
In my view, we are better off avoiding this whole thing and leaving it
to the individual implementations.
- - - - - - - - -
Date: 29 May 87 21:18 PDT
Subject: Issue: FUNCTION-TYPE (version 4)
From: Masinter.pa
Proposal FUNCTION-TYPE:REDEFINE
...
No sub-types of FUNCTION are defined in Common Lisp, but implementations
are free to define subtypes of FUNCTION. Examples might be
COMPILED-FUNCTION, INTERPRETED-FUNCTION, and so on. Note that this
is a change from the current Common Lisp definition which explicitly
defines a COMPILED-FUNCTION type. This proposal removes the predicate
COMPILED-FUNCTION-P from the standard language.
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:Moon@STONY-BROOK.SCRC.Symbolics.COM>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 01 JUN 87 21:23:10 PDT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun
87 21:21:48 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161267; Tue
2-Jun-87 00:11:30 EDT
Date: Tue, 2 Jun 87 00:11 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
This proposal removes the predicate
COMPILED-FUNCTION-P from the standard language.
If it also removes the COMPILED-FUNCTION type-specifier, say so here.
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:Masinter.pa@Xerox.COM>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 13 JUL 87 12:58:35 PDT
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 13 Jul 87 12:54:07
PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 13 JUL 87 12:54:07 PDT
Date: 13 Jul 87 12:53 PDT
From: Masinter.pa
... My notes [from X3J13 meeting] include ... that we be more consistent
about justifying removing COMPILED-FUNCTION-P (i.e., why bother?) ...
- - - - - - - - -
Date: 23 Oct 87 11:51 PDT
From: Masinter.pa
Subject: Issue: FUNCTION-TYPE (Version 6)
here is a revised version... I left COMPILED-FUNCTION and
COMPILED-FUNCTION-P as subtypes of FUNCTION.
...
Proposal FUNCTION-TYPE:STRICT-REDEFINITION
...
The COMPILED-FUNCTION subtype of FUNCTION is defined; implementations are
free to define other subtypes of FUNCTION, e.g., INTERPRETED-FUNCTION.
- - - - - - - - -
(wording preserved through several iterations)
- - - - - - - - -
Return-Path: <CL-Cleanup-mailer@SAIL.Stanford.EDU>
Redistributed: xerox-cl-cleanup↑.pa
Received: from SAIL.Stanford.EDU by Xerox.COM ; 16 FEB 88 09:41:39 PST
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 16 Feb 88
09:39:23 PST
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA23751; Tue, 16 Feb 88 10:39:08 MST
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA25191; Tue, 16 Feb 88 10:39:04 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8802161739.AA25191@orion.utah.edu>
Date: Tue, 16 Feb 88 10:39:02 MST
Also, I have a question about 1b, where it states that COMPILED-FUNCTION
is a subtype of FUNCTION. Does this imply that it must be a *proper*
subtype? For example, in the Lisp I've been working on sporadically for
my Atari, the interpreted version of (FUNCTION (LAMBDA ...)) returns a
compiled function object (it's a closure which will apply the lambda
expression to the function arguments). Likewise I can conceive of
implementations which compile everything and don't have an "interpreter"
at all. I think this needs to be clarified.
- - - - - - - - -
Return-Path: <CL-Cleanup-mailer@SAIL.Stanford.EDU>
Redistributed: xerox-cl-cleanup↑.pa
Received: from SAIL.Stanford.EDU by Xerox.COM ; 19 FEB 88 14:37:22 PST
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 19 Feb 88 14:34:11
PST
Received: from Cabernet.ms by ArpaGateway.ms ; 19 FEB 88 14:17:33 PST
Date: 19 Feb 88 14:17 PST
From: Masinter.pa
I intended not to require that it not be a "proper" subtype in the sense
that
there may be no data items that are FUNCTIONP but not COMPILED-FUNCTIONP.
This can be clarified.
- - - - - - - - -
Return-Path: <edsel!jonl@labrea.Stanford.EDU>
Received: from labrea.Stanford.EDU by Xerox.COM ; 24 FEB 88 10:14:38 PST
Received: by labrea.Stanford.EDU; Wed, 24 Feb 88 09:35:20 PST
Received: from bhopal.lucid.com by edsel id AA21578g; Wed, 24 Feb 88
10:03:43 PST
Received: by bhopal id AA26979g; Wed, 24 Feb 88 10:09:26 PST
Date: Wed, 24 Feb 88 10:09:26 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Lucid Common Lisp distinguishes "compiled" closures which exist for the
purpose of supporting entry into the interpreter from functions which are
truly compiled. It only takes a bit in a header word. If an
implementation
really doesn't support an interpreter, then having every function be
COMPILED-FUNCTIONP doesn't sound like much of a loss.
But most implementations in fact do support an interpreter -- which
typically runs code at anywhere from 30 to 600 times slower than when
compiled. Thus it seems reasonable to require COMPILED-FUNCTIONP in
those implementations to be false on, say,
(eval '#'(lambda (x) (list x)))
no matter what underlying technique is used to support interpreter
closures.
- - - - - - - - -
Date: 4 Sep 88 13:39 PDT
From: Masinter.pa
Subject: Issue: FUNCTION-TYPE (version 12)
line-fold: NO
This is the final version of the FUNCTION-TYPE issue, as passed at the June
88 X3J13 meeting; that is, it incorporates the amendments that were adopted
before the issue was adopted.
...
1b. Define that the type COMPILED-FUNCTION is a subtype of FUNCTION.
Implementations are free to define other subtypes of FUNCTION.
∂16-Mar-89 0701 @Score.Stanford.EDU:ball@polya.Stanford.EDU efficient use of computers
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Mar 89 07:01:48 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Thu 16 Mar 89 06:58:15-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA21360; Thu, 16 Mar 89 06:57:57 -0800
Date: Thu, 16 Mar 89 06:57:57 -0800
From: Jim Ball <ball@polya.Stanford.EDU>
Message-Id: <8903161457.AA21360@polya.Stanford.EDU>
To: wheaton@Athena.Stanford.EDU
Cc: jlh@vsop.Stanford.EDU, GENESERETH@score.Stanford.EDU, jcm@ra.Stanford.EDU,
faculty@score.Stanford.EDU, jlh@vsop.Stanford.EDU
In-Reply-To: George S Wheaton's message of Wed, 15 Mar 89 21:47:37 -0800 <8903160547.AA00224@Athena.Stanford.EDU>
Subject: efficient use of computers
CF uses various parts of the SU system for monitoring and control of
the status of purchase orders on-line. We also tie into some of the
student database information for Sharon Hemenway.
-Jim
∂16-Mar-89 0713 X3J13-mailer Issue: TIME-ZONE-NON-INTEGER, v.1
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 07:13:51 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 07:07:49 PST
Date: 16 Mar 89 07:07 PST
From: masinter.pa@Xerox.COM
To: x3J13@sail.stanford.edu
Subject: Issue: TIME-ZONE-NON-INTEGER, v.1
line-fold: NO
Message-ID: <890316-070749-3717@Xerox>
!
Issue: TIME-ZONE-NON-INTEGER
References: Section 25.4.1 (Time Functions) (p. 443-444)
Category: CLARIFICATION
Edit history: 1-MAR-89, Version 1 by Chapman
Problem Description:
CLtL states that the time zone part of Decoded Time is an integer. However,
it is possible to have a non-integer time-zone.
Proposal (TIME-ZONE-NON-INTEGER:ALLOW)
Specify that the time zone part of Decoded Time is a rational number
(either an integer or a ratio).
Rationale:
For CL to accommodate all possible time designations, it is necessary
to allow time zone to be non-integer.
Some places in the world are on half-hour or quarter-hour times.
Current Practice:
VAX LISP allows time zone to be non-integer.
Adoption Cost:
Shouldn't be too big a change.
Benefits:
See Rationale.
Conversion Cost:
See Adoption Cost.
Aesthetics:
None.
Discussion:
∂16-Mar-89 0708 CL-Compiler-mailer Re: Issue SAFE-CODE, version 1
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 07:08:22 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 07:03:17 PST
Date: 16 Mar 89 07:02 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue SAFE-CODE, version 1
In-reply-to: Dick Gabriel <RPG@SAIL.Stanford.EDU>'s message of 15 Mar 89
14:51 PST
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
cc: cl-compiler@SAIL.Stanford.EDU, x3j13@SAIL.Stanford.EDU
Message-ID: <890316-070317-3708@Xerox>
I'm guessing that Moon's objections are more serious than yours.
Frankly, as long as we're playing definitions, I think the problem lies
with
"Define that, formally, the term ``safe code'' is code refers to any
code in which the OPTIMIZE quality for SAFETY has a value of 3."
I don't think this is a good definition. It is probably good to define that
"any code in which the OPTIMIZE quality for SAFETY has a value 3" is "safe
code", but there is other code that is "safe" too.
It seems pretty awkward to say that:
(locally (declare (optimize (safety 0))) (list 1 2 3))
is "unsafe" or "nonsafe" or "potentially non-safe". We could use the words
that way, but it is pretty confusing.
Counter-proposal: say "declared safe" or "not declared safe", since the
issue is not the (English) safety of the code but the declarations in
effect?
∂16-Mar-89 0719 X3J13-mailer Re: issue LOAD-TIME-EVAL, version 11
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 16 Mar 89 07:19:03 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA21484; Thu, 16 Mar 89 08:16:34 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA05509; Thu, 16 Mar 89 08:16:32 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903161516.AA05509@defun.utah.edu>
Date: Thu, 16 Mar 89 08:16:30 MST
Subject: Re: issue LOAD-TIME-EVAL, version 11
To: masinter.pa@Xerox.COM
Cc: x3j13@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM, 16 Mar 89 06:45 PST
> Date: 16 Mar 89 06:45 PST
> From: masinter.pa@Xerox.COM
>
> Um, I looked for and didn't find a justification for why what was passed at
> the last meeting was inadequate. I'm puzzled as to why there are now two
> proposals when there was one before, what the differences are between them,
> etc.
What happened is that we got some e-mail on this issue after the
meeting, describing in more detail some objections to the wording of
the proposal that had been discussed very briefly at the meeting.
This person thought that the original wording was too vague and that
we would have trouble being more explicit about the semantics it was
intended to specify, and suggested some new wording for slightly
different semantics. I think it is the consensus of the compiler
committee that the new language is an improvement.
The changed section of the proposal is clearly marked in the writeup
that was distributed. It has to do with under what circumstances it
is permissible to cache LOAD-TIME-VALUE expressions.
-Sandra
-------
∂16-Mar-89 0720 X3J13-mailer Issue: LOAD-TRUENAME (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 07:20:34 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 07:13:53 PST
Date: 16 Mar 89 07:13 PST
From: masinter.pa@Xerox.COM
Subject: Issue: LOAD-TRUENAME (Version 1)
To: x3J13@SAIL.Stanford.EDU
Message-ID: <890316-071353-3747@Xerox>
!
Issue: LOAD-TRUENAME
Forum: Cleanup
References: LOAD (p426), PROVIDE (p188), REQUIRE (p188),
Issue REQUIRE-PATHNAME-DEFAULTS
Category: ADDITION
Edit history: 13-Mar-89, Version 1 by Pitman
Problem Description:
It is difficult to construct sets of software modules which work
together as a unit and which port between different implementations.
REQUIRE and PROVIDE were intended to provide this level of support
but have `failed' to be portable in practice.
Typical user configurations involve a `system definition' file which
loads the modules of a `system' (collection of software modules).
Among the specific problems which arise are:
- File system types may vary. Different file syntax must be used for
each site.
- Even with the same Lisp implementation and host file system type,
the directory in which a software system resides may differ from
delivery site to delivery site.
- Multiple `copies' of the same system may reside in different
directories on the same machine.
Proposal (LOAD-TRUENAME:NEW-PATHNAME-VARIABLES):
Introduce new variables:
*LOAD-TRUENAME* [Variable]
This special variable is initially NIL, but is bound by LOAD to
hold the truename of the pathname of the file being loaded.
*COMPILE-FILE-TRUENAME* [Variable]
This special variable is initially NIL, but is bound by
COMPILE-FILE to hold the truename of the pathname of the file
being compiled.
Example:
------ File SETUP ------
(IN-PACKAGE 'MY-STUFF)
(DEFMACRO COMPILE-TRUENAME () `',*COMPILE-FILE-TRUENAME*)
(DEFVAR *SOURCE-FILE* (COMPILE-TRUENAME) "Just for debugging.")
(DEFVAR *LOADED-FILE* *LOAD-TRUENAME*)
(DEFUN LOAD-MY-SYSTEM ()
(DOLIST (MODULE-NAME '("FOO" "BAR" "BAZ"))
(LOAD (MERGE-PATHNAMES MODULE-NAME *LOAD-TRUENAME*))))
------------------------
(LOAD "SETUP")
(LOAD-MY-SYSTEM)
Rationale:
This satisfies the most common instances of the frequently reported
problem in the Problem Description.
Current Practice:
Wide variation.
In some implementations, calling LOAD binds or sets
*DEFAULT-PATHNAME-DEFAULTS* so that pathnames named in a file being
LOADed will default to being `nearby.'
Some implementations provide special variables that are similar or
identical to one or both of those proposed.
Some implementations have a way to represent the pathname for the
current working directory, and make the default pathname default
to that, so that loading without specifying a default again tends to
get `nearby' files.
None of these techniques is portable, unfortunately, because there
is no agreement.
Cost to Implementors:
Very small.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Continued difficulty for anyone trying to put a system of modules
in a form where they can be conveniently delivered using portable code.
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
Negligible.
Discussion:
Touretzky raised the issue most recently on Common-Lisp. A number
of people immediately jumped on the bandwagon, indicating it was
important to them, too.
Pitman made three suggestions in response, of which the above is
the first. The others included:
2. Variables *LOAD-TRUENAMES* and *COMPILE-FILE-TRUENAMES* which hold
lists of the truenames of all files being loaded or compiled,
respectively, during the dynamic invocation of LOAD and COMPILE-FILE.
3. Variable *LOAD-OR-COMPILE-FILE-TRUENAMES* which holds a list like
((LOAD truename) (COMPILE-FILE truename) ...)
during the dynamic invocation of LOAD and COMPILE-FILE.
Touretzky responded:
``I like KMP's proposals. I like the second one best: have separate
variables for files being loaded and files being compiled, and use
them to maintain a stack so we can see the nesting of loads within
files.''
Pitman ultimately chose to present the first rather than the second
because it seemed simpler, easier to explain, and more likely to
pass at this late date.
!
Additional Comments:
"I favor LOAD-TRUENAME:NEW-PATHNAME-VARIABLES. I think this
proposal would be greatly improved by adding two more variables,
*LOAD-PATHNAME* and *COMPILE-FILE-PATHNAME*, whose values are
the pathname opened by LOAD or COMPILE-FILE, rather than the
truename. The need for these is more obvious if you think
about systems where the pathname cannot be easily reconstructed
from the truename. This includes file systems with symbolic
links and some pathname systems with logical pathnames."
"I favor this. I would even favor either of the other two ideas even at
this `late date'. The behavior of each of the proposals is simple, its
easy to see what it will and won't do, and it satisfies a real demand.
I should note that I have never wanted the incremented functionally
offered by the `stack' proposals, but I could still vote for them."
∂16-Mar-89 0831 X3J13-mailer Issue DESCRIBE-UNDERSPECIFIED, v.1
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 08:31:39 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 08:20:29 PST
Date: 16 Mar 89 08:19 PST
From: masinter.pa@Xerox.COM
Subject: Issue DESCRIBE-UNDERSPECIFIED, v.1
To: x3j13@SAIL.STANFORD.EDU
line-fold: NO
Message-ID: <890316-082029-3881@Xerox>
!
Forum: Cleanup
Issue: DESCRIBE-UNDERSPECIFIED
References: CLtL p441-2
88-002R, DESCRIBE function
Category: CHANGE, ADDITION
Edit history: Version 1, 10-Mar-89, Kim A. Barrett
Problem description:
The CLOS Specification (X3J13 Document 88-002R) changes the definition of the
function DESCRIBE, making it a generic function. However, it does not specify
any of the protocol needed to make user-defined methods interact properly to
produce some of the effects mentioned in CLtL. For example, CLtL says that
sometimes the method for describing an object will involve describing
something that it finds inside the object, and that such recursive
descriptions are indented appropriately. How do user-written methods achieve
this indentation? Must they arrange for the indentation explicitly, or is
there some automatic mechanism that handles it?
The new specification does not easily lend itself to certain kinds of features
which some implementations have included in their versions of DESCRIBE, such
as analogues to the printer's depth limits (*PRINT-DEPTH*) and circular
structure detection during recursion (*PRINT-CIRCLE*).
In addition, DESCRIBE does not take a stream argument, instead always doing
output to *STANDARD-OUTPUT*. This means that a program which wants to use
DESCRIBE to output some information to a particular stream must rebind
*STANDARD-OUTPUT* around the call to DESCRIBE. This is a nuisance, and is
also potentially a bad idea in implementations which have interrupts and such.
Proposal DESCRIBE-UNDERSPECIFIED:DESCRIBE-OBJECT:
Remove the section of 88-002R which specifies that DESCRIBE is a generic
function. Modify DESCRIBE to accept an optional second stream argument, which
defaults to *STANDARD-OUTPUT*. The value of this argument is the stream which
output will be directed to. Specify that DESCRIBE is implemented in terms of
the generic function DESCRIBE-OBJECT, described below.
DESCRIBE-OBJECT object stream [Generic Function]
The generic function DESCRIBE-OBJECT writes a description of an object to a
stream. The function DESCRIBE-OBJECT is called by the DESCRIBE function; it
should not be called by the user.
Each implementation is required to provide a method on the class
STANDARD-OBJECT and methods on enough other classes so as to ensure that
there is always an applicable method. Implementations are free to add
methods for other classes. Users can write methods for DESCRIBE-OBJECT for
their own classes if they do not wish to inherit an implementation-supplied
method.
ARGUMENTS:
The first argument is any Lisp object. The second argument is a stream; it
cannot be T or NIL.
VALUES:
The values returned by DESCRIBE-OBJECT are unspecified.
REMARKS:
Methods on DESCRIBE-OBJECT may recursively call DESCRIBE. Indentation,
depth limits, and circularity detection are all taken care of automatically,
provided that each method handles exactly one level of structure and calls
DESCRIBE recursively argument if there are more structural levels.
If this rule is not obeyed, the results are undefined.
In some implementations the stream argument passed to a DESCRIBE-OBJECT
method is not the original stream, but is an intermediate stream that
implements parts of DESCRIBE. Methods should therefore not depend on the
identity of this stream.
Rationale:
This proposal was closely modeled on the CLOS description of PRINT-OBJECT,
which was well thought out and provides a great deal of functionality and
implementation freedom. The same implementation techniques applicable to
PRINT-OBJECT will be applicable to DESCRIBE-OBJECT.
The reason for making the return values for DESCRIBE-OBJECT unspecified is to
avoid forcing users to include explicit (VALUES) in all their methods.
DESCRIBE will take care of that.
Current practice:
Probably nobody does precisely what this proposal suggests.
Cost to Implementors:
A fair amount of work may be required, since every method/subfunction of
DESCRIBE in an implementation may need at least some fixing to be in line with
this proposal. On the other hand, that work may already be needed in order to
conform to 88-002R, and this proposal may make the conversion easier by
simplifying the translation of an existing implementation of DESCRIBE.
Cost to Users:
Any users who are using an implementation which supports the current CLOS
specification of DESCRIBE and have defined their own methods will have to
change them. CLOS is sufficiently recent that this probably isn't a big
problem.
Those users who have made use of implementation-specific hooks into DESCRIBE
to define their own methods will likely have to change, but that was already
the case.
Users who are currently binding *STANDARD-OUTPUT* around calls to DESCRIBE may
wish to change their code.
Cost of non-adoption:
Portable DESCRIBE methods may be difficult to write because the protocol they
must follow is insufficiently specified.
Benefits:
The constraints on DESCRIBE methods are better specified, making it easier to
write such methods properly.
Aesthetics:
Minimal.
Discussion:
An additional change which is not included in the present proposal would be to
make the syntax of DESCRIBE and DESCRIBE-OBJECT be
DESCRIBE object &optional stream &key
DESCRIBE-OBJECT object stream &key
allowing implementation-specific extensions to the arguments. A possible
standard keyword argument is :VERBOSE, which might be used to specify how much
output to produce.
It might be desirable to define some new describe control variables analogous
to the printer control variables, ie. *DESCRIBE-LEVEL* and *DESCRIBE-CIRCLE*,
and possibly *DESCRIBE-LENGTH*.
-------
----- End Forwarded Messages -----
∂16-Mar-89 0854 X3J13-mailer Issue: CLOS-CONDITIONS (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 08:54:08 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 08:44:08 PST
Date: 16 Mar 89 08:43 PST
From: masinter.pa@Xerox.COM
Subject: Issue: CLOS-CONDITIONS (Version 4)
To: X3J13@SAIL.Stanford.EDU
line-fold: NO
Message-ID: <890316-084408-3922@Xerox>
There've been various comments on this version; most of the
relevant discussion centers on whether the metaclass of
condition classes should be specified. Exerpts from
the mail appear at the end.
!
Status: DRAFT
Issue: CLOS-CONDITIONS
References: Condition System (Revision 18)
Category: ADDITION
Edit history: 26-Sep-88, Version 1 by Pitman
06-Oct-88, Version 2 by Pitman
09-Oct-88, Version 3 by Pitman
10-Mar-89, Version 4 by Pitman (remove unsupported options)
Problem Description:
The description of the Common Lisp condition system presupposes
only DEFSTRUCT and not DEFCLASS because it was written when
CLOS had not been adopted. It is stylistically out of step with
CLOS in a few places and places some restrictions which are not
necessary if CLOS can be presupposed.
Proposal (CLOS-CONDITIONS:INTEGRATE):
1. Define that condition types are CLOS classes.
2. Define that condition objects are CLOS instances.
3. Functions such as SIGNAL, which take arguments of class names, are
permitted to take class objects. Such class objects must still be
subclasses of CONDITION.
4. Define that slots in condition objects are normal CLOS slots. Note
that WITH-SLOTS can be used to provide more convenient access to the
slots where slot accessors are undesirable.
5. Incompatibly change the syntax of a slot in DEFINE-CONDITION
to be compatible with a DEFCLASS slot specification.
An implication of this change is that forms like
(DEFINE-CONDITION FOO (BAR) ((A 1) (B 2)))
would have to be written
(DEFINE-CONDITION FOO (BAR)
((A :INITARG :A :READER FOO-A :INITFORM 1)
(B :INITARG :B :READER FOO-B :INITFORM 2)))
6. Permit multiple parent-types to be named in the list of parent types.
Define that these parent types are treated the same as the superior
class list in a CLOS DEFCLASS expression.
7. Eliminate the :CONC-NAME option to DEFINE-CONDITION.
8. Define that condition reporting is mediated through the PRINT-OBJECT
method for the condition type (class) in question, with *PRINT-ESCAPE*
always being NIL. Specifying (:REPORT fn) in the definition of a
condition type C is equivalent to doing
(DEFMETHOD PRINT-OBJECT ((X c) STREAM)
(IF *PRINT-ESCAPE* (CALL-NEXT-METHOD) (fn X STREAM)))
Rationale:
These changes are consistent with the intent of the X3J13 endorsement
of CLOS and the Common Lisp Condition System.
Although items 5 and 7 are incompatible with the interim condition
handling which we've been working with, the overall proposal significantly
improves compatibility with CLOS.
This compatibility will make the language seem less fragmented, and
probably more learnable because there will be fewer paradigms to learn.
Also, items 5 and 7 in particular are an improvement for reasons
unrelated to CLOS if only because they get rid of the need for symbol
concatenation, a process which has been seen to cause problems because
of the transient nature of the binding of *PACKAGE*.
Examples:
Slot specifiers...
A slot specifier of X is still valid but is incompatibly
changed to mean what CLOS has it mean; no :INITARG or
:READER would be supplied.
A slot specifier of (X) is still valid but is incompatibly
changed to mean what CLOS has it mean; no :INITARG or
:READER would be supplied.
A slot specifier of (X V) would no longer be valid.
In addition, other slot specifiers such as
(X :INITARG :EX :TYPE FIXNUM)
are permitted as in DEFCLASS.
Conc names ...
(DEFINE-CONDITION FOOBAR (FOO BAR) (X Y) (:CONC-NAME FUBAR))
would be rewritten
(DEFINE-CONDITION FOOBAR (FOO BAR)
((X :INITARG :X :READER FUBAR-X)
(Y :INITARG :Y :READER FUBAR-Y)))
Report methods ...
(DEFINE-CONDITION OOPS (ERROR) ())
(DEFMETHOD PRINT-OBJECT ((X OOPS) STREAM)
(IF *PRINT-ESCAPE*
(CALL-NEXT-METHOD)
(FORMAT STREAM "Oops! Something went wrong.")))
(ERROR 'OOPS)
>>Error: Oops! Something went wrong.
Current Practice:
Some implementations supporting CLOS probably already do this,
or something very similar.
Cost to Implementors:
If you really have CLOS, this is very straightforward.
Cost to Users:
Small, but tractable.
The main potential problems are:
- :CONC-NAME. There is nothing that keeps an implementation from
continuing to support :CONC-NAME for a short while until old code
has been upgraded.
- The incompatible change to slot syntax. Again, it is possible to
unambiguously recognize a 2-list as old-style syntax and an
implementation can provide interim compatibility support during
a transition period.
Even if implementations did not provide the recommended compatibility
support, users could trivially shadow DEFINE-CONDITION and provide the
support themselves, expanding into the native DEFINE-CONDITION in the
proper syntax.
In any case, the total number of uses of DEFINE-CONDITION at this
point is probably quite small. Searching for them and repairing
each by hand is probably not an expensive operation.
Cost of Non-Adoption:
Conditions will seem harder to manipulate than other user-defined types.
People will wonder if CLOS is really something we're committed to.
Benefits:
A more regular, more learnable language.
Aesthetics:
Improved.
Discussion:
Gregor, Pierson, Moon, and Pitman support this proposal.
People seem to disagree about the status that CLOS might occupy
in the upcoming standard. In spite of a vote of support, they seem
to think it might be optional in some way. Passing this proposal
establishes a clear precedent for the full integration of CLOS into
the emerging language.
The sense of the cleanup committee was that it was acceptable for
a vendor to identify a CLOS-free subset of Common Lisp, but that since
the position of X3J13 seems to be that no resources should be devoted
to work on subsets, it was inappropriate for us to work out the details
of that subset ourselves. Since nothing about this proposal would
impede such a subset, we took that to be adequate basis for presenting
this single proposal.
Moon thinks we might want to add condition types for the errors
CLOS might signal. Richard Mlynarik thinks we should add a generic
function, REPORT-CONDITION, which is used for reporting conditions.
Both of these issues should probably be pursued under separate cover.
!
"One comment is that you should explicitly mention bootstrapping
concerns under cost to implementors. If you just leave it out,
someone may think it is a difficult problem. "
"This isn't any sort of clarification. The actual clarification required
-- which has been requested several times, and not just by myself -- is
what the *METACLASS* of condition types is.
Condition types may be "CLOS classes" without being STANDARD-CLASSes
Condition objects may be "CLOS instances" without being STANDARD-OBJECTs.
Just what are "normal CLOS slots"? As I see it, the "normalcy" or
otherwise of slots is determined by the metaclass.
My opinion for some time has been that condition types should not be
STANDARD-CLASSes but instead something like READ-ONLY-CLASS.
Conceptually, It Is An Error to modify the slots of condition objects,
which are supposed to be immutable descriptions of part of the state of
a computation. Implementationally,
(setf (slot-value <condition-object> <slot-name>) <new-value>) should
signal an error.
(I also think that conditions in particular have a strong need for
something like :REQUIRED-INIT-KEYWORDS, but that's another story.)
Even if you decide to make condition classes' metaclass STANDARD-CLASS,
the point is that you need to state this, so that users may define
condition classes and mixins using DEFCLASS."
"I do not agree that it is a -necessary- thing to specify the Meta-Class
of conditions because all intended uses of conditions can be done
without this information.
I agree that it is a -possibly useful- thing to do, but there is a down
side to it -- it would unnecessarily tie the hands of people who want
implementation flexibility for one reason or another."
"... If we don't specify the metaclass, then users
won't know what other classes they can mix in when defining condition
classes. It may seem weird, but I can imagine someone wanting to mix
in an arbitrary class into a condition class.
I think we should just say that the class CONDITION is an instance of
STANDARD-CLASS, and that by default DEFINE-CONDITION defines standard
classes. Sure it might be nice to do the read only class thing but I
don't think this is a good time to design a special purpose metaclass
for this. "
∂16-Mar-89 0928 CL-Compiler-mailer Issue SAFE-CODE, version 1
To: cl-compiler@SAIL.Stanford.EDU
CC: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
The point of these definitions is to lay out terminology that
enables programmers to know with certainty on what ground they stand
with respect to the specification. ``Safe code'' is a technical term
that means that the code was ``processed'' under this declaration.
This means intuitively that it is as safe (English word) as it can get.
But it also means that it is ``safe code'' in the CL jargon, and eveything
we say about safe code there is also true of it.
The meaning of safe code (English phrase), as in ``as safe as it can
get,'' is spelled out in the specification as the sequence of statements
we make about the attributes of safe code. It might be that some or all of
those attributes apply to code processed under lower safety optimization
levels, but the programmer can be sure only when the highest safety level
is used.
I think Moon's problem is that the usual practice is to borrow English
words for these technical terms, and that works fine until the
negation of the term is needed. We want some word to mean ``not `safe' ''.
``Unsafe'' is an available English word that does not mean the
complement of ``safe'', it means the reverse of safe. Thus, the parallel
senses of the technical pair ``safe/unsafe'' are not the same as the
vernacular pair safe/unsafe.
Also, the definitions of the terms point out that what is defined as
``unsafe code'' might actually be exactly as safe (English) as ``safe code.''
-rpg-
∂16-Mar-89 0957 X3J13-mailer Re: Issue ERROR TERMINOLOGY, dpANS C
Received: from Aquinas.Think.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 09:57:06 PST
Received: from OCCAM.THINK.COM by Aquinas.Think.COM via CHAOS with CHAOS-MAIL id 124431; Wed 15-Mar-89 19:28:46 EST
Date: Wed, 15 Mar 89 19:28 EST
From: Barry Margolin <barmar@FAFNIR.THINK.COM>
Subject: Re: Issue ERROR TERMINOLOGY, dpANS C
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
cc: Cris Perdue <cperdue@sun.com>, chapman <@decwrl.dec.com:chapman@aitg.dec>,
kempf <@sun.com:kempf@clam>, peck <@sun.com:peck@clam>, sgadol <@sun.com:sgadol@clam>,
x3j13@sail.stanford.edu, cl-editorial@sail.stanford.edu, rpg <@sail.stanford.edu:rpg@lucid.com>
In-Reply-To: <2039.8903151921@subnode.aiai.ed.ac.uk>
Message-ID: <19890316002837.0.BARMAR@OCCAM.THINK.COM>
A while back I proposed (to the Editorial committee) a definition of
"harmless" that I still like: Equivalent to an arbitrary conforming
program. The point of this definition is to say that the consequences
of the situation are undefined, but it can't do anything that a valid
program can't do (if we had a denotational semantics, or a virtual
machine specification as I believe the C standard does, we could
probably use that to specify this). For instance, it won't result in
pointers to unallocated data being stored in the application's data, or
changing components of function objects. Undefined consequences would
allow such things, and they can result in secondary effects such as
crashing the system or the process dumping core. Note that my
definition includes signaling an error among the harmless consequences.
Yes, this definition allows such situations to result in playing chess,
and if the computer is controlling a bomb silo it could also result in
starting World War III. I don't think a general definition of
"unspecified" can possibly disallow these things. We might want to
rethink the applicability of the word "harmless" in this case. I think
market forces are adequate to guarantee that the actual results in any
particular implementation will be reasonable, and we won't have
computers all over the country playing chess when you ask them to CONS.
By the way, I've decided that the "consequences of the garbage collector
are unspecified" example is totally bogus. The garbage collector is
completely transparent to a Common Lisp program. The usual
counterargument (which I used to give) is that GC usually changes the
output of the ROOM function, but so can CONS, MAKE-ARRAY, etc.; the
language doesn't even guarantee that (PROGN (ROOM) (ROOM)) will print
the same output twice (it probably won't if ROOM conses). It can also
be argued that GC can be detected by noticing how long operations take,
but on time-sharing systems there are other reasons why an operation may
take a long time. GC may reorder the elements in a hash table, but we
never guarantee that MAPHASH of a hash table will consistently process
the elements in the same order, and SETF of GETHASH may also rehash the
table. I challenge someone to write a conforming Common Lisp program
GC-P that takes as an argument a function, applies the function, and
returns a boolean result indicating whether a GC occurred during the
function execution.
If we can't come up with another example of an unspecified situation,
perhaps we should just throw out the term and stop fighting about it.
barmar
∂16-Mar-89 0958 X3J13-mailer Re: Issue: EXTRA-RETURN-VALUES
Received: from Aquinas.Think.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 09:57:58 PST
Received: from OCCAM.THINK.COM by Aquinas.Think.COM via CHAOS with CHAOS-MAIL id 124433; Wed 15-Mar-89 19:37:26 EST
Date: Wed, 15 Mar 89 19:37 EST
From: Barry Margolin <barmar@FAFNIR.THINK.COM>
Subject: Re: Issue: EXTRA-RETURN-VALUES
To: David N Gray <Gray@dsg.csc.ti.com>
cc: chapman%aitg.DEC@decwrl.dec.com, x3j13@sail.stanford.edu
In-Reply-To: <2814888931-7906489@Kelvin>
Message-ID: <19890316003719.1.BARMAR@OCCAM.THINK.COM>
Date: Tue, 14 Mar 89 11:35:31 CST
From: David N Gray <Gray@dsg.csc.ti.com>
> Proposal: EXTRA-RETURN-VALUES:NO
> Unless it is explicitly allowed in the standard,
> if a standard function
> returns a different number of return values from the number
> specified by the standard, the results are unspecified.
>
>
> Rationale:
>
> The reason is that
> additional arguments are visible to otherwise portable programs. "For
> instance, (multiple-value-call #'cons (floor x y)) looks portable, but it
> will try to pass the wrong number of arguments to CONS if FLOOR returns an
> extra value."
This may be a bit of over-kill. I suggest making this restriction only
for functions which the standard specifies as returning multiple values.
For functions that the standard says return one value, there would be no
reason for a portable program to go out of its way to accept more than
one value from them, so additional values shouldn't hurt.
But MULTIPLE-VALUE-CALL permits multiple arguments, some of which might
be calls to functions documented as returning only one valid, e.g.
(multiple-value-call #'three-arg-function (cons x y) (floor x y))
MV-CALL is being used to get the multiple values of FLOOR passed as the
second and third argument to THREE-ARG-FUNCTION, but this will fail if
CONS returns the wrong number of values.
barmar
∂16-Mar-89 1004 @Score.Stanford.EDU:jutta@coyote.stanford.edu faculty candidate visits
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 16 Mar 89 10:04:42 PST
Received: from coyote.stanford.edu by SCORE.STANFORD.EDU with TCP; Thu 16 Mar 89 10:00:15-PST
Received: by coyote.stanford.edu; Thu, 16 Mar 89 10:06:31 PST
Date: 16 Mar 1989 1006-PST (Thursday)
From: Jutta McCormick <jutta@coyote.stanford.edu>
To: faculty@score.Stanford.EDU
Cc:
Subject: faculty candidate visits
The Robotics Search Committee will be interviewing the following
candidates within the next two or so weeks:
Friday, March 17: Zexiang Li, U.C. Berkeley (Ph.D.student)
Monday and Tuesday,
March 20 and 21: Michael Erdmann, M.I.T. (Ph.D. student)
Monday, April 3
(tentative): John Aloimonos, U. of Maryland (Ass't.Professor)
Below is the information on the talks the first two candidates are
scheduled to present. Information on Aloimonos' talk will follow as
soon as it is available.
If you are interested in meeting with any of the candidates, please
send mail to jutta@coyote.
SPECIAL ROBOTICS SEMINAR
Speaker: Zexiang Li
U.C. Berkeley
Title: DEXTROUS ROBOT HANDS: PLANNING AND CONTROL
Date: Friday, March 17, 1989
Time: 3:30 p.m.
Place: Cedar Hall Conference Room
ABSTRACT
To understand the operation of a dextrous robot hand, we need to solve the
following two important problems:
(1) autonomously adjusting grasp configurations without dropping the
object and
(2) task execution by coordinated manipulation of the fingers
with appropriate contact models.
Since rolling constraint and twirling operations are involved in the first
problem, a hand manipulation system is a non-holonomic system. Consequently,
the corresponding planning problem becomes very difficult.
In this talk, we first define a grasp configuration and the above two
canonical problems. Then we study motion of two objects under rolling
constraint. For this, we set up the problem so that Frobenius-Lie theory
can be used to verify the existence of motion between two contact
configurations, and a solution will be constructed based on the contact
geometries, should a solution exist. Our results show that a ball
is able to reach any contact configurations (by rolling) relative to the
plane, but not to another ball of the same radius. Finally, we propose a set
of control laws for coordinated manipulation by the fingers under three
contact models: (a) fixed points of contact, (b) rolling contact and
(c) rigid contact. The control law achieves not only the desired trajectory
of the object but also the desired internal grasp force. Simulation and
experimental results of these control laws will also be given.
SPECIAL ROBOTICS SEMINAR
Speaker: Michael Erdmann
M.I.T.
Title: MOTION PLANNING WITH UNCERTAINTY: A PROBABILISTIC APPROACH
Date: Monday, March 20, 1989
Time: 4:00 p.m.
Place: Cedar Hall Conference Room
Abstract to follow.
∂16-Mar-89 0958 CL-Compiler-mailer Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
Received: from Aquinas.Think.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 09:58:47 PST
Received: from OCCAM.THINK.COM by Aquinas.Think.COM via INTERNET with SMTP id 124445; 16 Mar 89 12:31:52 EST
Date: Thu, 16 Mar 89 12:31 EST
From: Barry Margolin <barmar@FAFNIR.THINK.COM>
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
To: masinter.pa@xerox.com
cc: cl-compiler@sail.stanford.edu, X3J13@sail.stanford.edu
In-Reply-To: <890316-062330-3633@Xerox>
Message-ID: <19890316173142.7.BARMAR@OCCAM.THINK.COM>
I'll just reiterate something I said at one of the meetings. One
portable use I can think of for the COMPILED-FUNCTION type is as a
declaration to allow compiler optimization. If a function knows (or
requires) that a parameter is a compiled function it can declare that
and the implementation may be able to optimize the FUNCALL better.
Another thing I just thought of is something like:
(when (typep f '(and function (not compiled-function)))
(setq f (compile nil f)))
This doesn't actually work because COMPILE isn't required to accept
lexical closures (well, at least it doesn't accept them in Genera 7.2),
but they satisfy the type specifier, but it would be nice if there were
a standard set of primitives that would allow one to write something
that does what the above tries to do.
barmar
∂16-Mar-89 1040 X3J13-mailer Re: Issue ERROR TERMINOLOGY
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 16 Mar 89 10:40:10 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa08149; 16 Mar 89 18:31 GMT
Date: Thu, 16 Mar 89 18:29:06 GMT
Message-Id: <2499.8903161829@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue ERROR TERMINOLOGY
To: Dick Gabriel <RPG@sail.stanford.edu>, x3j13@sail.stanford.edu
In-Reply-To: Dick Gabriel's message of 15 Mar 89 1446 PST
> Is it the case that ``fatal'' is well-defined? If so, ``harmless'' is
> simply something that is not fatal. According to my mathematics
> education, that renders the term well-defined.
"Harmless" does not mean "not fatal".
"Undefined" means the standard imposes no constraints (and irrational
implementors can do whatever they want and still have a conforming
implementation). But "unspecified" imposes some constraints. I
didn't find "harmless" a sufficiently enlightening description of
these constraints. If no one feels inclined to suggest something
better now, I am happy to wait and see how "unspecified" gets used in
the standard before deciding whether or not "harmless" works.
∂16-Mar-89 1044 X3J13-mailer Issue: CLOSED-STREAM-OPERATION (Version 7)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 10:44:15 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 09:51:25 PST
Date: 16 Mar 89 09:43 PST
From: masinter.pa@Xerox.COM
Subject: Issue: CLOSED-STREAM-OPERATION (Version 7)
To: x3j13@sail.stanford.edu
line-fold: NO
Message-ID: <890316-095125-4330@Xerox>
Version 5 of issue CLOSED-STREAM-OPERATION was brought up at
the January 1989 meeting.
The proposal CLOSED-STREAM-FUNCTIONS:ALLOW-INQUIRY was amended at
that meeting; the amended version passed.
Version 5 said
"If CLOSE is called on a stream which is open, it will return T.
However, if CLOSE is called on a stream which is closed, it
will succeed without error but the return value is not specified."
The amendment was to change the wording so that CLOSE would
return NIL if given a closed stream, viz:
" If CLOSE is called on a stream which is open, it will return T.
However, if CLOSE is called on a stream which is closed, it
will succeed with out error but the return value will be NIL."
Kent Pitman has made an argument that the amendment
was ill-considered.
I find his argument convincing.
I think procedurally we can vote to reconsider &
revoke the amendment, i.e., revert to Version 5.
Excerpts from the discussion:
Return-Path: <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Received: from STONY-BROOK.SCRC.Symbolics.COM ([128.81.41.144]) by Xerox.COM ; 06 FEB 89 10:12:19 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 534168; Mon 6-Feb-89 13:11:33 EST
Date: Mon, 6 Feb 89 13:11 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
...
I think one ought not be able to depend
on the result in this case [of CLOSE of a closed stream]
because implementations might reasonably differ
about whether the first CLOSE really closed the stream. As such,
(LIST (CLOSE *TERMINAL-IO*) (CLOSE *TERMINAL-IO*))
might reasonably return (T T) or (T NIL), for example, depending on whether
the implementation represents the concept of `open-ness' for all streams.
The same is true for string streams.
The issue is even weirder for composite (eg, broadcast) streams where some
streams are initially open and others are not, since I think we have no
clear theory of whether such a stream is opened or closed.
...
Return-Path: <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Received: from STONY-BROOK.SCRC.Symbolics.COM ([128.81.41.144]) by Xerox.COM ; 15 FEB 89 07:04:19 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 539477; Wed 15-Feb-89 10:03:58 EST
Date: Wed, 15 Feb 89 10:03 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
What's weird about this whole thing is that CLOSE-CONSTRUCTED-STREAM
talks about the effect of most operations being `unspecified' after
CLOSE.
Unless you intend it to be an implication of CLOSE-CONSTRUCTED-STREAM
that you actually carry a CLOSED-P bit around in every stream so you
can tell if the stream is open or not and return the right value from
CLOSE, then it's a bad idea to legislate that CLOSE returns a certain
value, because you can't really guarantee that value.
If you do intend me to carry around a CLOSED-P bit, why bother to
claim that the effect of I/O to the stream after it's closed is
`unspecified.' My assumption before was that it was unspecified in
case I want to define it, but suddenly it sounds like I'm not really
allowed to extend it -- I'm just permitted to optimize out the error
checks for the sake of efficiency. If this is so, why not just put it
in the domain of `should signal' so that at least the users could get
some mileage out of it because my implementation pretty much has its
hands tied at this point.
We get calls all the time from users who claim we're in violation of
things that really CLtL leaves vague. This will be such a thing given
the way it's all worded.
Here I am implementing CLOSE. I -really- want to implement it correctly.
I am willing to do anything necessary to make it return the right value
as long as what I do is something that is backed up in writing.
Here you are designing CL -- creating the writing that will back me up.
If you cannot show me how to write CLOSE in a way so that I can simply
point to a sentence in the manual that explains off my behavior whenever
anyone complains so I can get them off the phone and get back to work,
then you owe me a sentence in the manual that says that I'm entitled to
do whatever I feel like and the user cannot depend on it.
False security is worse than no security at all.
∪End of message∪
∂16-Mar-89 1051 X3J13-mailer Re: Issue ERROR TERMINOLOGY, dpANS C
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 16 Mar 89 10:51:31 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA06620; Thu, 16 Mar 89 13:49:18 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA07280; Thu, 16 Mar 89 13:47:38 EST
Message-Id: <8903161847.AA07280@mist.>
To: Barry Margolin <barmar@FAFNIR.THINK.COM>
Cc: x3j13@sail.stanford.edu, cl-editorial@sail.stanford.edu
Subject: Re: Issue ERROR TERMINOLOGY, dpANS C
In-Reply-To: Your message of Wed, 15 Mar 89 19:28:00 -0500.
<19890316002837.0.BARMAR@OCCAM.THINK.COM>
Date: Thu, 16 Mar 89 13:47:36 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Date: Wed, 15 Mar 89 19:28 EST
From: Barry Margolin <barmar@FAFNIR.THINK.COM>
A while back I proposed (to the Editorial committee) a definition of
"harmless" that I still like: Equivalent to an arbitrary conforming
program. The point of this definition is to say that the consequences
of the situation are undefined, but it can't do anything that a valid
program can't do (if we had a denotational semantics, or a virtual
machine specification as I believe the C standard does, we could
probably use that to specify this). For instance, it won't result in
pointers to unallocated data being stored in the application's data, or
changing components of function objects. Undefined consequences would
allow such things, and they can result in secondary effects such as
crashing the system or the process dumping core. Note that my
definition includes signaling an error among the harmless consequences.
I like this idea.
∂16-Mar-89 0958 X3J13-mailer Issue: TIME-ZONE-NON-INTEGER, v.1
Received: from Aquinas.Think.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 09:58:20 PST
Received: from OCCAM.THINK.COM by Aquinas.Think.COM via INTERNET with SMTP id 124441; 16 Mar 89 12:16:49 EST
Date: Thu, 16 Mar 89 12:16 EST
From: Barry Margolin <barmar@FAFNIR.THINK.COM>
Subject: Issue: TIME-ZONE-NON-INTEGER, v.1
To: masinter.pa@xerox.com
cc: x3J13@sail.stanford.edu
In-Reply-To: <890316-070749-3717@Xerox>
Message-ID: <19890316171639.5.BARMAR@OCCAM.THINK.COM>
Date: 16 Mar 89 07:07 PST
From: masinter.pa@xerox.com
Proposal (TIME-ZONE-NON-INTEGER:ALLOW)
Specify that the time zone part of Decoded Time is a rational number
(either an integer or a ratio).
Just to show you, when I become a billionaire I'll form my own country
and give it an irrational time zone (e in the winter, sqrt(2) in the
summer).
Seriously, is there any particular reason not to allow any non-complex
number as a time zone?
barmar
∂16-Mar-89 1044 X3J13-mailer Issue: COERCE-INCOMPLETE (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 10:44:26 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 09:59:01 PST
Date: 16 Mar 89 09:57 PST
From: masinter.pa@Xerox.COM
Subject: Issue: COERCE-INCOMPLETE (Version 3)
To: x3j13@sail.stanford.edu
line-fold: NO
Message-ID: <890316-095901-4371@Xerox>
There are some additional comments at the end.
!
Issue: COERCE-INCOMPLETE
Reference: COERCE (p50)
Category: ADDITION/CHANGE
Edit history: Version 1 of COERCE-INCOMPLETE, 26-Feb-88 by M. Ida
Version 1 of COERCE-FROM-TYPE, 20-Jun-88 by Pitman
Version 2 of COERCE-INCOMPLETE, 21-Nov-88 by Pitman
(consolidate previous two proposals)
Version 3 of COERCE-INCOMPLETE, 07-Mar-89 by Pitman
(eliminate unpopular proposal, two new options)
Problem Description:
COERCE is difficult to extend because ambiguities arise about the
source type of the coercion.
For example, if the symbol STRING were permitted as a second argument
to coerce, as in (COERCE NIL 'STRING), there would be two posssible
return values: "" or "NIL". The choice would be arbitrary and would
have to be specified by the documentation. No matter which was chosen,
it would probably turn out to be a problem for some applications at
some times.
Another example is (COERCE (CHAR-CODE #\A) 'STRING). This might
return the same as (FORMAT NIL "~D" (CHAR-CODE #\A)) -- "65" in
most ASCII-based implementations -- or it might return "A". Again,
the choice would be arbitrary.
There is clear desire on the part of the user community to lift some of
the existing restrictions on arguments to COERCE, but because of legitimate
concerns about ambiguities, the Common Lisp designers have thus far
refused to do so.
Unfortunately, the failure of COERCE to handle these cases means it is
very difficult to learn to use COERCE. And the fact that COERCE is not
easily learned contributes to difficulty in learning Common Lisp because
instead of a single coercion operator with general purpose semantics, a
number of very special purpose coercion operators must be learned instead.
Some middle ground needs to be found, which neither compromises the
clear semantics and portable nature of COERCE nor complicates COERCE
in a way that makes it unlearnable.
Also, some people have expressed a desire for COERCE to be more
`symmetric.' Usually they seem to mean that they want it to be the case
that if (COERCE x y) works, then (COERCE (COERCE x y) (TYPE-OF x))
should also work. Although this is not an essential desire, it would
certainly be nice to achieve.
Proposal (COERCE-INCOMPLETE:LIMITED-ARBITRARY-EXTENSION):
Define COERCE to accept the following equivalences:
1. (COERCE x 'STRING) == (STRING x)
2. (COERCE x 'PATHNAME) == (PATHNAME x)
3. (COERCE x 'RATIONAL) == (RATIONAL x)
Clarify that
4. (COERCE x 'FLOAT) == (FLOAT x)
Rationale:
Many users think of STRING, for example, as ``the way to coerce
something to a string'' and are baffled why COERCE and STRING
disagree on how to do this.
Such users think that if there's a moral battle to be waged
over how to coerce an object to a STRING, the battle has already
been lost by defining the STRING function -- that whatever
decision is made for STRING must also apply to COERCE for the
sake of simplicity.
Similar arguments can be made for PATHNAME, FLOAT, and RATIONAL.
Proposal (COERCE-INCOMPLETE:DEPRECATE):
Deprecate COERCE.
Rationale:
COERCE is not functionally necessary -- no operation that it does
cannot be done in some other way. As such, it is basically just
a matter of syntactic convenience, and perhaps isn't worth having
around if it will be the subject of endless debate. Deprecating
it would allow us to declare this issue a `dead end' and focus our
attention on matters of greater substance.
Current Practice:
Presumably No one implements either of the proposals at this time,
since none are compatible with CLtL.
Cost to Implementors:
COERCE: Small to moderate.
DEPRECATE: None.
Cost to Users:
COERCE: This is an incompatible change. (COERCE 'NIL 'STRING) => ""
but (STRING NIL) => "NIL". How many applications are impacted by
this change is not clear. It would be straightforward to shadow
COERCE with an alternate definition that did the old thing in
cases where people were worried. Once such cases have been
identified, rewriting
(COERCE X 'STRING)
as
(IF X (COERCE X 'STRING) "")
will suffice in most cases.
DEPRECATE: No immediate work would be needed, although many maintained
applications would get upgraded in order to use the primitives that
are `in vogue.'
Cost of Non-Adoption:
People will continue to see and debate the issues alluded to in
the Problem Description.
Benefits:
The cost of Non-Adoption will be avoided.
Aesthetics:
COERCE: Many people will probably see the idea of making
COERCE consistent with STRING, PATHNAME, FLOAT, and
RATIONAL as a clear improvement -- possibly outweighing
the costs of both an incompatible change and a decision
to arbitrarily favor one treatment over the other.
DEPRECATE: Some may take the deprecation of COERCE as an
aesthetic improvement because it eliminates the need to
debate this issue further. Others may see the
``de-centralization'' of coercion as a step backward.
Discussion:
Pitman supports COERCE-INCOMPLETE:LIMITED-ARBITRARY-EXTENSION.
Hopefully Moon and Masinter support it, too, since it's
basically patterned after a bunch of mail they were sending
back and forth.
A proposal to extend COERCE to permit a ``view type'' argument
was considered and rejected as too extreme to consider seriously
in the timeframe available.
Pierson suggests that COERCE ought to be a candidate for
generic function status.
Pitman thinks that making [two-argument] COERCE generic would
be a -very- bad idea but believes that his earlier proposal
involving a third `view type' argument might be able to
accomodate such extension.
!
Additional comments:
"... The thing about
COERCE-INCOMPLETE:LIMITED-ARBITRARY-EXTENSION that strikes fear
into my heart is that it wipes out CLtL's simple statement that
any sequence type may be converted to any other sequence type,
and starts people asking questions like does
(coerce nil '(vector character)) => "" or "NIL"?
... I'm inclined to vote
no on both proposals and keep the (unsatisfactory) status quo."
"I believe that any change to the status quo is incomplete without
providing a coercion mechanism whose "viewpoint" is that of a sequence.
That is effectively what the current COERCE is, overloaded with those
types which do not conflict with SEQUENCE.
Because of the problem of differing viewpoints, I'm inclined to think
that COERCE should be shrunk down to only being a sequence coercion
function, and all other coercions should be handled by the appropriate
functions."
∂16-Mar-89 1045 X3J13-mailer DRAFT Issue: CONDITION-RESTARTS (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 10:44:53 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 10:30:53 PST
Date: 16 Mar 89 10:24 PST
From: masinter.pa@Xerox.COM
Subject: DRAFT Issue: CONDITION-RESTARTS (Version 1)
To: x3j13@SAIL.Stanford.EDU
line-fold: NO
Message-ID: <890316-103053-4587@Xerox>
There will possibly be a new version of this issue available
at the meeting. Additional comments excerpted at the end...
!
Issue: CONDITION-RESTARTS
Forum: Cleanup
References: Common Lisp Condition System
Category: CHANGE
Edit history: 18-Jan-89, Version 1 by Pitman
Problem Description:
It was noted in the condition system document itself, and many people have
complained privately, that a major weakness of the condition system is the
inability to know whether a particular restart is associated with a
particular signalling action.
The problem being addressed shows itself in situations involving recursive
errors. The programmer wants to make sure that a restart obtained from
FIND-RESTART or COMPUTE-RESTARTS is in fact present for the purpose of
handling some particular error that he is actively focussed on, and not
for some other (outer) error which he was not actively trying to handle.
Proposal (CONDITION-RESTARTS:PERMIT-ASSOCIATION):
1. Define that it is an error for SIGNAL to be called on a condition
more than once.
2. Introduce a function COPY-CONDITION:
COPY-CONDITION condition [Function]
Returns a copy of the given condition.
3. Introduce a macro WITH-CONDITION-RESTARTS which can be used to
dynamically bind the association between a condition and a set
of restarts.
WITH-CONDITION-RESTARTS (condition-form restarts-form) &BODY forms
[Macro]
Evaluates CONDITION-FORM and RESTARTS-FORM, the results of which
should be a condition and a list of restarts, respectively. Then
evaluates the body of forms in implicit-progn style, returning the
last form. While in the dynamic context of the body, the function
COMPUTE-RESTARTS will, when given an argument that was the result
of evaluating the CONDITION-FORM, return the list of restarts that
was the result of evaluating the RESTARTS-FORM.
Only the innermost call to WITH-CONDITION-RESTARTS with a given
condition is relevant. In this way, the set of restarts associated
with a given condition can be dynamically extended or restricted.
Usually this macro is not used explicitly in code, since
SIGNAL-WITH-RESTARTS and ERROR-WITH-RESTARTS handle most of the
common cases in a way that is syntactically more concise.
4. Extend COMPUTE-RESTARTS, FIND-RESTART, ABORT, CONTINUE, USE-VALUE,
and STORE-VALUE to permit an optional condition object as an argument.
When the extra argument is not supplied, these functions behave
exactly as defined before. (Restarts are considered without
prejudice to whether they have been associated with conditions.)
When this argument is supplied, only restarts with the associated
with the given condition are considered. In all other respects, the
behavior is the same.
Passing a condition argument of NIL is treated the same as passing
no condition argument.
5. Add two new macros SIGNAL-WITH-RESTARTS and ERROR-WITH-RESTARTS:
SIGNAL-WITH-RESTARTS condition &rest restart-clauses [Macro]
This does several things:
1. It enters a context in which the indicated RESTART-CLAUSES
are available. They have the same form as the clauses in
a RESTART-CASE.
2. It evaluates CONDITION expression. [This is done after the
restarts are instantiated because the restarts are probably
still useful in the debugger if an error occurs during the
evaluation of the condition.] The result of the evaluation
must be a condition object.
3. It associates the condition which resulted from the evaluation
with the restarts established in step 1, using the equivalent
of WITH-CONDITION-RESTARTS.
4. It calls SIGNAL on the same condition.
ERROR-WITH-RESTARTS condition &rest restart-clauses [Macro]
Like SIGNAL-WITH-RESTARTS but uses ERROR rather than SIGNAL
in step 4.
6. Define that Common Lisp macros such as CHECK-TYPE, which are defined
to signal and to make restarts available, use the equivalent of
WITH-CONDITION-RESTARTS to associate the conditions they signal with
the defined restarts, so that users can make reliable tests not only
for the restarts being available, but also for them being available
for the right reasons.
Rationale:
1. The ability to recycle a condition object (including the ability to
resignal a condition) means that the same condition object might be
simultaneously active for two different purposes. In such a case,
no test (not even EQ) would suffice to determine whether a particular
restart belonged with a particular signalling action, since the
condition could not uniquely identify the signalling action. By saying
that a given condition may only be signalled once, we guarantee that
the condition can serve as a unique identifier for a signalling action.
2. Since there may now be some code which has begun to rely on the ability
to re-signal a condition, COPY-CONDITION will help to make this
transition easier. Instead of
(SIGNAL already-signalled-condition)
one can write:
(SIGNAL (COPY-CONDITION already-signalled-condition))
3. This is is the minimal level of support needed to set up an
association between restarts and conditions.
4. This provides a natural interface for retrieving and using the
information about the associations between conditions and restarts.
5. This provides a natural interface for the most common case of
wanting to signal a restart with some associated conditions.
Test Case:
(HANDLER-BIND ((ERROR #'(LAMBDA (C) (SIGNAL C)))) (SIGNAL "Test"))
was permissible, but this proposal makes it an error.
(DEFUN TEST-CONDITION-STUFF (OFFER-EXTRA-RESTART
USE-CONDITION-ARGUMENT
USE-FOUND-RESTART)
(HANDLER-BIND ((CONDITION
#'(LAMBDA (C)
(LET ((R0 (FIND-RESTART 'USE-VALUE))
(R1 (IF USE-CONDITION-ARGUMENT
(FIND-RESTART 'USE-VALUE C)
(FIND-RESTART 'USE-VALUE))))
(IF (AND R1 USE-FOUND-RESTART)
(INVOKE-RESTART R1 (EQ R0 R1))
(USE-VALUE (EQ R0 R1)))))))
(HANDLER-BIND ((CONDITION
#'(LAMBDA (C)
(USE-VALUE
(IF OFFER-EXTRA-RESTART
(WITH-RESTARTS
(SIGNAL (COPY-CONDITION C))
(USE-VALUE (X) (LIST 'EXTRA X)))
(SIGNAL (COPY-CONDITION C)))))))
(SIGNAL-WITH-RESTARTS (MAKE-CONDITION 'SIMPLE-CONDITION
:FORMAT-STRING "Test")
(USE-VALUE (X) X)))))
Previously, this was an error because it uses non-existent primitives, but
if you assume that
- COPY-CONDITION is implemented in the `obvious' way
- SIGNAL-WITH-RESTARTS just uses WITH-RESTARTS and SIGNAL
- FIND-RESTART ignores its last argument
in the obvious naive ways, it is possible to compare the old and new behavior:
Current Proposed
(TEST-CONDITION-STUFF NIL NIL NIL) => T T
(TEST-CONDITION-STUFF NIL NIL T) => T T
(TEST-CONDITION-STUFF NIL T NIL) => T T
(TEST-CONDITION-STUFF NIL T T) => T T
(TEST-CONDITION-STUFF T NIL NIL) => T (EXTRA T)
(TEST-CONDITION-STUFF T NIL T) => T (EXTRA T)
(TEST-CONDITION-STUFF T T NIL) => T (EXTRA NIL)
(TEST-CONDITION-STUFF T T T) => T NIL
Current Practice:
Presumably no implementation does this yet.
Cost to Implementors:
Several small, relatively modular changes.
Cost to Users:
Except for the change to the recyclability of restarts, this change is
upward compatible.
Probably very few if any users currently take advantage of recycling
restarts, so the cost to users of this change is very slight.
Even in the case where recycling is used, a straightforward rewrite in
terms of COPY-CONDITION is probably feasible.
Cost of Non-Adoption:
Use of restarts would not be nearly as reliable.
Benefits:
It would be possible to write code which was considerably more robust.
Aesthetics:
Some people might consider this proposal to make things slightly better
because it avoids some ambiguities. Others might consider it to make
things slightly worse because it adds additional complexity.
Discussion:
Pitman thinks a change of this sort is important.
!
"CONDITION-RESTARTS:PERMIT-ASSOCIATION looks fine to me.
It would certainly clean things up in some code I'm working on.."
"I strongly favor this proposal; it removes the major objection that I
had to the CL condition system as it developed.
However, I don't favor the COPY-CONDITION function. I don't think it's
necessary. More importantly, you have not proposed any concrete specification
of what it does, and unless someone does, it cannot be included in the
language. Fortunately, I think we can just drop it, as I doubt that any
portable program would use it in any significant way that could not just
as well be done with a tiny amount of code using other existing primitives.
[generally agreed]
" .. how (should) the condition/restart association
might be implemented -- is some kind of alist structure held by a
special variable what was intended, or ought the condition have a
restarts slot? ... it's pretty obvious that the relation should be externally
represented. It's important that the association not be done by a slot
in the condition because if you carry around the condition object after
you're done signalling, you don't want it to contain useless and/or
misleading information about restarts that no longer exist."
"... syntax to SIGNAL-WITH-RESTARTS and
ERROR-WITH-RESTARTS should be:
SIGNAL-WITH-RESTARTS signal-argument-list &rest restart-clauses
ERROR-WITH-RESTARTS signal-argument-list &rest restart-clauses
so that you would write
(SIGNAL-WITH-RESTARTS ('FOOD-COLOR-ERROR :FOOD 'LETTUCE :COLOR 'PINK)
...restart clauses...)
rather than
(SIGNAL-WITH-RESTARTS (MAKE-CONDITION 'FOOD-COLOR-ERROR
:FOOD 'LETTUCE :COLOR 'PINK)
...restart clauses...)
If you wanted to use MAKE-CONDITION, you would then write:
(SIGNAL-WITH-RESTARTS ((MAKE-CONDITION 'FOOD-COLOR-ERROR
:FOOD 'LETTUCE :COLOR 'PINK))
...restart clauses...)
The advantage of what he proposes is that you could write
(SIGNAL-WITH-RESTARTS ("Bad ~S color" 'FOOD)
...restart clauses...)
and a condition object would be created implicitly as with SIGNAL. A
possible disadvantage is that
(SIGNAL-WITH-RESTARTS (FOO BAR BAZ)
...restart clauses...)
might look to someone like the FOO in (FOO BAR BAZ) named a function
rather than a variable. "
"... even better would be
(WITH-CONDITION-RESTARTS signal-form &rest restart-clauses)
where signal-form must be an invocation of SIGNAL, ERROR, WARN, or
perhaps a few others, or a macro that expands into such an invocation.
WITH-CONDITION-RESTARTS must signal an error at all levels of safety if
it does not recognize the signal-form. This is "weird" because it uses
a form for something other than evaluation (but not unprecedented; this
is exactly what SETF does). The advantage is that it just nests with an
existing syntax instead of inventing a new, awkward syntax.
Note that I stole the "good name" WITH-CONDITION-RESTARTS for this
commonly used syntax. The less commonly used primitive that just sets
up the restarts without signalling doesn't need as good a name."
"... the syntax for WITH-CONDITION-RESTARTS should be
WITH-CONDITION-RESTARTS condition-form restarts-form &BODY forms
rather than
WITH-CONDITION-RESTARTS (condition-form restarts-form) &BODY forms
which it is now. Does anyone else have an opinion?
This is probably a good idea. I'd probably name this one
WITH-CONDITION-RESTARTS-INTERNAL. But are we sure that this operation
needs to be named in the standard
"
∂16-Mar-89 1117 CL-Compiler-mailer issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 11:16:55 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558656; Thu 16-Mar-89 14:13:55 EST
Date: Thu, 16 Mar 89 14:13 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
To: Aaron Larson <alarson@src.honeywell.com>
cc: cl-compiler@sail.stanford.edu, x3j13@sail.stanford.edu
In-Reply-To: <8903160338.AA16529@pavo.src.honeywell.com>
Message-ID: <19890316191343.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 15 Mar 89 21:38:06 CST
From: alarson@src.honeywell.com (Aaron Larson)
If we permit the compiler to signal warnings for functions where the
compile-time environment signature is different from the function call
being compiled, why do we prohibit it for generic functions?
I would say that what CLOS-MACRO-COMPILATION (which I have not reviewed yet)
is clearly incorrect. Perhaps CLOS-MACRO-COMPILATION was trying only to rule
out signalling an error for a lack of lambda-list congruency between
compile-time and run-time, but went overboard and ruled out warnings
as well. I think warnings in this circumstance can be desirable, but
errors are certainly wrong.
∂16-Mar-89 1146 X3J13-mailer Issue ERROR TERMINOLOGY, dpANS C
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 11:44:03 PST
Received: from fafnir.think.com by Think.COM; Thu, 16 Mar 89 14:40:15 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Thu, 16 Mar 89 14:41:04 EST
Received: by verdi.think.com; Thu, 16 Mar 89 14:37:31 EST
Date: Thu, 16 Mar 89 14:37:31 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903161937.AA05048@verdi.think.com>
To: barmar@Think.COM
Cc: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK, cperdue@sun.com,
@decwrl.dec.com:chapman@aitg.dec, @sun.com:kempf@clam,
@sun.com:peck@clam, @sun.com:sgadol@clam, x3j13@sail.stanford.edu,
cl-editorial@sail.stanford.edu, @sail.stanford.edu:rpg@lucid.com
In-Reply-To: Barry Margolin's message of Wed, 15 Mar 89 19:28 EST <19890316002837.0.BARMAR@OCCAM.THINK.COM>
Subject: Issue ERROR TERMINOLOGY, dpANS C
Date: Wed, 15 Mar 89 19:28 EST
From: Barry Margolin <barmar@Think.COM>
A while back I proposed (to the Editorial committee) a definition of
"harmless" that I still like: Equivalent to an arbitrary conforming
program ...
Yes, this definition allows such situations to result in playing chess,
and if the computer is controlling a bomb silo it could also result in
starting World War III. I don't think a general definition of
"unspecified" can possibly disallow these things. We might want to
rethink the applicability of the word "harmless" in this case....
How about renaming "harmless" to be "arbitrary"?
--Guy
∂16-Mar-89 1205 X3J13-mailer Issue: TIME-ZONE-NON-INTEGER, v.1
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 12:03:57 PST
Received: from fafnir.think.com by Think.COM; Thu, 16 Mar 89 14:41:11 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Thu, 16 Mar 89 14:42:22 EST
Received: by verdi.think.com; Thu, 16 Mar 89 14:39:11 EST
Date: Thu, 16 Mar 89 14:39:11 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903161939.AA05061@verdi.think.com>
To: barmar@Think.COM
Cc: masinter.pa@xerox.com, x3J13@sail.stanford.edu
In-Reply-To: Barry Margolin's message of Thu, 16 Mar 89 12:16 EST <19890316171639.5.BARMAR@OCCAM.THINK.COM>
Subject: Issue: TIME-ZONE-NON-INTEGER, v.1
Date: Thu, 16 Mar 89 12:16 EST
From: Barry Margolin <barmar@Think.COM>
Date: 16 Mar 89 07:07 PST
From: masinter.pa@xerox.com
Proposal (TIME-ZONE-NON-INTEGER:ALLOW)
Specify that the time zone part of Decoded Time is a rational number
(either an integer or a ratio).
Just to show you, when I become a billionaire I'll form my own country
and give it an irrational time zone (e in the winter, sqrt(2) in the
summer).
Seriously, is there any particular reason not to allow any non-complex
number as a time zone?
barmar
When you become a billionaire, you'll probably find that
you get a better approximation to e or sqrt(2) with a moby
bignum rational than with a float.
--Quux
∂16-Mar-89 1212 X3J13-mailer Issue: COPY-SYMBOL-COPY-PLIST, v.1
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 12:12:12 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 11:27:49 PST
Date: 16 Mar 89 11:27 PST
From: masinter.pa@Xerox.COM
Subject: Issue: COPY-SYMBOL-COPY-PLIST, v.1
To: x3j13@sail.stanford.edu
line-fold: NO
Message-ID: <890316-112749-4871@Xerox>
The only discussion on this issue was whether it was necessary
to clarify (some thought it was) and whether a more general
"copy the list means COPY-LIST" was necessary (probably not.)
There was no controversy on the proposal itself.
!
Issue: COPY-SYMBOL-COPY-PLIST
References: COPY-SYMBOL (p 169), COPY-LIST (p 268), COPY-TREE (p
269).
Category: CLARIFICATION
Edit history: 10-Jan-89, Version 1 by Margolin
Problem Description:
The description of COPY-SYMBOL, where the COPY-PROPS optional argument
is non-NIL, says that a copy of the property list is used as the new
symbol's property list. However, there are several ways in which a list
may be copied, most notably COPY-LIST and COPY-TREE, and the description
doesn't say which mechanism should be used.
Proposal (COPY-SYMBOL-COPY-PLIST:COPY-LIST)
Clarify that when COPY-SYMBOL copies the property list of the symbol, it
is as if (COPY-LIST (SYMBOL-PLIST sym)) were used as the new symbol's
property list.
Rationale:
COPY-LIST is the simplest list-copying primitive. The result of this
copy is that GET returns EQL results for the two symbols until one of
the property lists is altered, but altering either of the property lists
doesn't affect the other. This is current practice in the
implementations I tested, and probably what most users assume.
Current Practice:
Symbolics Genera and Sun Common Lisp currently implement this. I
suspect most others do, too.
Cost to Implementors:
Little or none.
Cost to Users:
None unless they've been assuming some other type of copy.
Benefits:
Less ambiguity.
Aesthetics:
Well, I like it.
∂16-Mar-89 1221 X3J13-mailer Issue DESCRIBE-UNDERSPECIFIED, v.1
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 12:20:58 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558750; Thu 16-Mar-89 15:18:32 EST
Date: Thu, 16 Mar 89 15:18 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue DESCRIBE-UNDERSPECIFIED, v.1
To: masinter.pa@Xerox.COM, Kim A. Barrett <IIM@ECLA.USC.EDU>
cc: x3j13@SAIL.STANFORD.EDU
In-Reply-To: <890316-082029-3881@Xerox>
Message-ID: <19890316201824.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
I think this is unnecessary, but I do not strongly oppose it.
The proposed division of labor between the DESCRIBE function and
the DESCRIBE-OBEJCT generic function could be implemented by
an :AROUND method for the existing DESCRIBE generic function.
The claim that binding *STANDARD-OUTPUT* is dangerous in the
presence of interrupts is false, since many things bind
*STANDARD-OUTPUT* and any reasonable interactive interrupt
handler must rebind the standard streams, the print control
variables, etc.
I don't strongly oppose this since it might be worthwhile just
for the symmetry with the PRINT-OBJECT generic function.
∂16-Mar-89 1241 X3J13-mailer Issue DYNAMIC-EXTENT: a remark
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 12:41:00 PST
Received: from fafnir.think.com by Think.COM; Thu, 16 Mar 89 15:36:50 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Thu, 16 Mar 89 15:38:04 EST
Received: by verdi.think.com; Thu, 16 Mar 89 15:34:53 EST
Date: Thu, 16 Mar 89 15:34:53 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903162034.AA05881@verdi.think.com>
To: masinter.pa@xerox.com
Cc: X3J13@sail.stanford.edu
In-Reply-To: masinter.pa@xerox.com's message of 16 Mar 89 11:59 PST <890316-120057-5042@Xerox>
Subject: Issue DYNAMIC-EXTENT: a remark
This is the last paragraph of the proposal DYNAMIC-EXTENT:NEW-DECLARATION:
The meaning of a dynamic extent declaration is that execution of the
forms in the scope of the declaration will not "save" any "proper part"
of the initial value of the declared variable. To "save" an object
means to cause a reference to that object to be accessible outside the
dynamic extent of the form at the beginning of whose body the
declaration appears. An object can be "saved" by storing it with a
side-effecting operation and not replacing it with a different value
before the end of the dynamic extent, by using it as a component of a
freshly-allocated object that is itself "saved," by capturing it in a
function closure that is itself "saved," by returning it as a value, or
by transmitting it outside the dynamic extent with THROW. A "proper
part" of an object A is any object that is accessible at the beginning
of the scope of the declaration -only- by applying a function to A or to
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
a "proper part" of A. This means that any objects freshly allocated
during the construction of the initial value of the declared variable,
and not "saved" during the construction of that value, are "proper
parts" and can be allocated on a stack.
I believe that the words indicated above should be replaced by
"the extent of the binding for which the delaration was made".
The reference appears to be to a point in time. Scopes are in space;
the beginning of a scope is a character position in the text (or
something like that). Extents are in time. Is this what you meant?
--Conan the Pedantrian (a.k.a. Guy)
∂16-Mar-89 1212 X3J13-mailer Issue: COPY-SYMBOL-PRINT-NAME, v.2
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 12:12:18 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 11:42:46 PST
Date: 16 Mar 89 11:29 PST
From: masinter.pa@Xerox.COM
Subject: Issue: COPY-SYMBOL-PRINT-NAME, v.2
to: X3J13@sail.stanford.edu
line-fold: NO
Message-ID: <890316-114246-4951@Xerox>
!
Issue: COPY-SYMBOL-PRINT-NAME
References: COPY-SYMBOL (p. 169)
Category: CLARIFICATION
Edit history: 1-MAR-89, Version 1 by Chapman
15-MAR-89, Version 2 by Chapman
Problem Description:
The description of COPY-SYMBOL states that it "returns a new uninterned
symbol with the same print name as sym (its first argument)". The words
"the same as" are not defined in CLtL. Do they mean EQ, EQUAL, ...?
Proposal (COPY-SYMBOL-PRINT-NAME:EQUAL)
The description of COPY-SYMBOL should read as follows:
"COPY-SYMBOL returns an uninterned
symbol whose print name is STRING= to
the print name of the symbol that is the first argument to COPY-SYMBOL."
Suggested implementation note:
The string should not be copied unnecessarily. In this case, the uninterned
symbol's print name would be EQ to the print name of the argument symbol.
Rationale:
This clarification resolves any possibility of ambiguity.
Current Practice:
Medley did this: the symbol names didn't really have a string header and
some symbol names (the "initial symbols" ) had a different place for
storing the actual characters than symbols created later. Unfortunately,
that means that SYMBOL-NAME has to CONS.
It wasn't so much a problem for Interlisp since most of the "string"
functions in Interlisp will take symbols, but in Common Lisp, it is a
performance hit. Poor design, but there's no reason to require SYMBOL-NAME
to return EQ strings.
In this case, the strings aren't EQ even though the string characters are
shared. (Think of it as strings displaced to a shared area.)
Adoption Cost:
?
Benefits:
Less ambiguity in the specification, and potentially more portable code.
Conversion Cost:
?
Aesthetics:
None.
Discussion:
∂16-Mar-89 1212 X3J13-mailer *DRAFT* Issue: DESTRUCTURING-BIND, v.2
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 12:12:27 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 11:49:11 PST
Date: 16 Mar 89 11:46 PST
From: masinter.pa@Xerox.COM
Subject: *DRAFT* Issue: DESTRUCTURING-BIND, v.2
to: X3J13@sail.stanford.edu
line-fold: NO
Message-ID: <890316-114911-4982@Xerox>
This issue is draft; there will hopefully be a new version before
the meeting.
The discussion centers around what lambda-list keywords should be
allowed.
&ENVIRONMENT:
everybody says disallow
&WHOLE:
Moon said allow (the second time.)
NIL:
Moon says allow as a way of ignoring.
KMP says OK, maybe in other places too.
Discussion of IGNORE led to new issue.
&BODY:
KMP makes case for disallowing, but says
allow.
There was some additional discussion that resulted in the
related issues of DEFMACRO-LAMBDA-LIST and IGNORE-VARIABLE.
I'd be happy with a proposal that said NIL is ignored,
&WHOLE and &BODY are allowed, and that &ENVIRONMENT
is disallowed. I'd like to make sure it was consistent
with LOOP.
!
Issue: DESTRUCTURING-BIND
Forum: Cleanup
References: DEFMACRO (CLtL pp145-151),
The LOOP Facility (X3J13/89-004)
Category: ADDITION
Edit history: 24-Jan-89, Version 1 by Pitman
25-Jan-89, Version 2 by Pitman
Status: For Internal Discussion
Problem Description:
Common Lisp programmers have frequently complained that the
destructuring facility used by DEFMACRO is not made available
for use in ordinary programming situations involving list data.
The presence of a destructuring facility in the recently adopted
LOOP facility will be likely to make the absence of a separable
destructuring facility all the more apparent.
Prior to the introduction of LET into Maclisp, many people wrote
their own LET macros. A popular expansion was in terms of a DO
which did not iterate. eg,
(LET ((A 3)) (+ A A)) ==> (DO ((A 3)) () (RETURN (+ A A)))
While this practice `worked,' it was not perspicuous and contributed
substantially to non-readability: not only were the macros hard to
understand, but the surface interface itself was not standardized
and varied in subtle ways. For example, some LET macros allowed GO
statements while others did not.
There is now considerable danger that a lot of people will write
DESTRUCTURING-BIND variants in terms of a LOOP expression that
immediately returns.
(DESTRUCTURING-BIND ((A B) C) (FOO) (LIST A B C))
==> (LOOP FOR ((A B) C) ON (FOO) DO (RETURN (LIST A B C)))
Since the destructuring offered by LOOP is different in subtle ways
from the destructuring offered by DESTRUCTURING-BIND in implementations
offering that primitive natively, gratuitous headaches could result.
Proposal (DESTRUCTURING-BIND:NEW-MACRO):
Provide a macro called DESTRUCTURING-BIND which behaves like the
destructuring bind in DEFMACRO. Specifically...
DESTRUCTURING-BIND lambda-list expression {decl|doc}* {form}* [Macro]
Binds the variables specified in LAMBDA-LIST to the corresponding
values in the tree structure resulting from evaluating EXPRESSION,
then evaluates the FORMS in the body.
Anywhere in the LAMBDA-LIST where a parameter name may appear, and
where ordinary lambda-list syntax (as described in CLtL section 5.2.2)
does not otherwise allow a list, a lambda-list may appear in place of
the parameter name. When this is done, then the argument form that
would match the parameter is treated as a (possibly dotted) list, to
be used as an argument forms list for satisfying the parameters in
the embedded lambda-list.
If any of the lambda list keywords &OPTIONAL, &REST, &KEY,
&ALLOW-OTHER-KEYS and &AUX appears in the lambda list, it is treated
as with any other lambda-list.
If the lambda list keyword &BODY appears, it is treated as a synonym
for &REST.
If the lambda list keyword &WHOLE appears, it must be followed by a
single variable that is bound to the entire expression at the current
level. &WHOLE and the following variable should appear first in the
list, before any other parameter or lambda-list keyword.
It is also permissible for any level of the LAMBDA-LIST to be dotted,
ending in a parameter name. This situation is treaed exactly as if
the aprameter name that ends the list had appeared preceded by &REST
in a proper list. For example, the notation (X Y . Z) is equivalent
to (X Y &REST Z).
If the result of evaluating the expression does not match the
destructuring pattern, the consequences are undefined. Implementations
are not required to signal an error in this case, but neither are they
permitted to extend the behavior by defining it to be harmless.
Clarify that the destructuring done by LOOP does not permit the use of
any lambda-list-keywords. Further clarify that in LOOP, proper lists
are implicitly `&REST var' (where the non-use of var is quietly ignored).
Hence, it is permissible to have:
(LOOP FOR (X Y) ON '(A B C D) COLLECT (CONS X Y)) => ((A . B) (C . D))
but it is not permissible to have:
(DESTRUCTURING-BIND (X Y) '(A B C D) (CONS X Y))
since the pattern does not match. One must instead write:
(DESTRUCTURING-BIND (X Y &REST Z) '(A B C D)
(DECLARE (IGNORE Z))
(CONS X Y))
Test Case:
(DEFUN IOTA (N) (LOOP FOR I FROM 1 TO N COLLECT I)) ;helper
(DESTRUCTURING-BIND ((A &OPTIONAL (B 'BEE)) ONE TWO THREE)
`((ALPHA) ,@(IOTA 3))
(LIST A B THREE TWO ONE))
=> (ALPHA BEE 3 2 1)
Rationale:
The proposal directly addresses the stated problem, and is current practice
in numerous implementations. Our charter effectively dictates that where
feasible we should try to head off the widespread development of uselessly
different variants of commonplace tools.
Current Practice:
Symbolics Genera, Envos Medley, TI Explorer, and Lucid CL all offer
DESTRUCTURING-BIND, though the details vary slightly.
The DESTRUCTURING-BIND offered by Symbolics Genera signals an error if
the pattern is not matched. The TI Explorer version does not.
Cost to Implementors:
Very small. In most cases, it's a matter of renaming and/or exporting an
already existing symbol. In a few cases, a very small amount of
`program interface' code would have to be written.
Cost to Users:
None. This is an upward compatible change.
Cost of Non-Adoption:
Loss of the Benefits and Aesthetics cited below.
Benefits:
Users will get a powerful feature they have asked for on many occassions.
In implementations which `autoload' code, it would be better for this
support to be separable so that people could do DESTRUCTURING-BIND
without demand loading all other LOOP support.
Aesthetics:
Defining this macro centrally for the Common Lisp community will reduce
subtle deviations, which will in turn have positive aesthetic impact.
Discussion:
JonL observes that although LOOP does destructuring, it can't directly
make use of the DESTRUCTURING-BIND interface suggested here.
Pitman and Gray think a facility of this sort is a good idea, though
obviously the details may still need a little fleshing out before the
proposal is ready for vote.
To date, the excuse for not satisfying this request has been a
religious war between factions who want to destructure lists by
writing
(DESTRUCTURING-BIND (var1 var2 var3) exp . body)
and those who want to destructure lists by writing
(DESTRUCTURING-BIND (LIST var1 var2 var3) exp . body)
The advantage of the former approach is that it is notationally
concise for the common case of destructuring a list. The disadvantage
is that it is not extensible to accomodate abstract kinds of
destructuring.
The advantage of the latter approach is that it allows interesting
extensions that accomodate data-hiding, such as:
(DEFMACRO MAKE-FOO (&REST ELEMENTS) `(LIST ,@ELEMENTS))
(DESTRUCTURING-BIND (MAKE-FOO var1 var2 var3) exp . body)
and later the ability to change the representation of a FOO without
updating the associated binding forms. The disadvantage is that it
is more verbose in the common case of destructuring a list, and still
even more verbose for nested lists.
Although destructuring has always existed in DEFMACRO, this has not
been adequate precedence for deciding the outcome of the religious war
because DEFMACRO only needs to destructure programs, and programs are
generally made up only of lists -- not arbitrary user-defined abstract
data types.
∂16-Mar-89 1213 X3J13-mailer
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 12:12:39 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 12:00:57 PST
Date: 16 Mar 89 11:59 PST
From: masinter.pa@Xerox.COM
To: X3J13@sail.stanford.edu
line-fold: NO
Message-ID: <890316-120057-5042@Xerox>
I think this is one of the more important issues to consider,
in that it is addresses one of the most frequently noted
performance issues in Common Lisp. We've examined a large number
of proposals and alternatives to allow declaration of dynamic extent
in Common Lisp.
!
Forum: CLEANUP
Issue: DYNAMIC-EXTENT
References: Scope and Extent
Category: ADDITION
Edit history: 27-Jun-88, Version 1 by Pitman (as issue STACK-LET)
15-Nov-88, Version 2 by Pitman (issue renamed, major revision)
11-Jan-89, Version 3 by Masinter (Moon's proposal)
Related-Issues: REST-ARGUMENT-EXTENT, WITH-DYNAMIC-EXTENT
Problem Description:
Sometimes a programmer knows that a particular data structure
will have only dynamic extent. In some implementations, it is
possible to allocate such structures in a way that will make them
easier to reclaim than by general purpose garbage collection
(eg, on the stack or in some temporary area). Currently, however,
there is no way to request the use of such an allocation mechanism.
Proposal (DYNAMIC-EXTENT:NEW-DECLARATION):
Introduce a new declaration called DYNAMIC-EXTENT. The arguments to
this declaration are names of variables. The declaration asserts that
the value which is initially held by the indicated variable will have
dynamic extent. [In the case of an iteration variable, the declaration
asserts that on every iteration, the initial value of that variable
for the iteration will have dynamic extent.]
It is permissible for an implementation to simply ignore this declaration.
In implementations which do not ignore it, the compiler (or interpreter)
is free to make whatever optimizations are appropriate given this
information; the most common optimization is to stack-allocate the
initial value of the object. What data types (if any) can have dynamic
extent will can vary from implementation to implementation.
Since stack allocation of the initial value entails knowing at the
object's creation time that the object can be stack-allocated, it is
not generally useful to declare DYNAMIC-EXTENT for variables for
which have no lexically apparent initial value. For example,
(DEFUN F ()
(LET ((X (LIST 1 2 3)))
(DECLARE (DYNAMIC-EXTENT X))
...))
would permit those compilers which wish to do so to stack-allocate the
list in X. However,
(DEFUN G (X) (DECLARE (DYNAMIC-EXTENT X)) ...)
(DEFUN F () (G (LIST 1 2 3)))
could not typically permit a similar optimization in G because it would
be a modularity violation for the compiler to assume facts about G from
within F. Only an implementation which was willing to be responsible for
recompiling F if G's definition changed incompatibly could stack-allocate
the list argument to G in F.
Other interesting cases are:
(PROCLAIM '(INLINE G))
(DEFUN G (X) (DECLARE (DYNAMIC-EXTENT X)) ...)
(DEFUN F () (G (LIST 1 2 3)))
and (DEFUN F ()
(FLET ((G (X) (DECLARE (DYNAMIC-EXTENT X)) ...))
(G (LIST 1 2 3))))
where some compilers might realize the optimization was possible and others
might not.
An interesting variant of this is the so-called `stack allocated rest list'
which can be achieved (in implementations supporting the optimization) by:
(DEFUN F (&REST X)
(DECLARE (DYNAMIC-EXTENT X))
...)
Note here that although the initial value of X is not explicit, the F
function is responsible for assembling the list X from the passed arguments,
so the F function can be optimized by the compiler to construct a
stack-allocated list instead of a heap-allocated list in implementations
which support such.
The meaning of a dynamic extent declaration is that execution of the
forms in the scope of the declaration will not "save" any "proper part"
of the initial value of the declared variable. To "save" an object
means to cause a reference to that object to be accessible outside the
dynamic extent of the form at the beginning of whose body the
declaration appears. An object can be "saved" by storing it with a
side-effecting operation and not replacing it with a different value
before the end of the dynamic extent, by using it as a component of a
freshly-allocated object that is itself "saved," by capturing it in a
function closure that is itself "saved," by returning it as a value, or
by transmitting it outside the dynamic extent with THROW. A "proper
part" of an object A is any object that is accessible at the beginning
of the scope of the declaration -only- by applying a function to A or to
a "proper part" of A. This means that any objects freshly allocated
during the construction of the initial value of the declared variable,
and not "saved" during the construction of that value, are "proper
parts" and can be allocated on a stack.
Examples:
In
(LET ((X (LIST 'A1 'B1 'C1))
(Y (CONS 'A2 (CONS 'B2 (CONS 'C2 NIL)))))
(DECLARE (DYNAMIC-EXTENT X Y))
...)
The "proper parts" of X are three conses, and the "proper parts" of Y
are three other conses. None of the symbols A1, B1, C1, A2, B2, C2, or
NIL is a "proper part" of X or Y. However, if a freshly allocated
uninterned symbol had been used, it would have been a "proper part."
- - - - - - - -
(DOTIMES (I N)
(DECLARE (DYNAMIC-EXTENT I))
This is particularly instructive. Since I is an integer by the
definition of DOTIMES, but EQ and EQL are not necessarily equivalent for
integers, what are the "proper parts" of I, which this declaration
requires the body of the DOTIMES not to "save"? If the value of I is 3,
and the body does (SETQ FOO 3), is that an error? The answer is no, but
the interesting thing is that it depends on the implementation-dependent
behavior of EQ on numbers. In an implementation where EQ and EQL are
equivalent for 3, then 3 is not a "proper part" because (EQ I (+ 2 1))
is true, and therefore there is another way to access the object besides
going through I. On the other hand, in an implementation where EQ and
EQL are not equivalent for 3, then the particular 3 that is the value of
I is a "proper part", but any other 3 is not. Thus (SETQ FOO 3) is valid
but (SETQ FOO I) is erroneous. Since (SETQ FOO I) is erroneous in some
implementations, it is erroneous in all portable programs, but some other
implementations may not be able to detect the error.
- - - - - - - -
(LET ((X (LIST 1 2 3)))
(DECLARE (DYNAMIC-EXTENT X))
(PRINT X)
NIL)
PRINT does not "save" any part of its input.
This prints (1 2 3)
- - - - - - - -
(DO ((L (LIST-ALL-PACKAGES) (CDR L)))
((NULL L))
(DECLARE (DYNAMIC-EXTENT L))
(PRINT (CAR L)))
prints all packages; none of the newly-allocated list structures are saved.
- - - - - - - -
(DEFUN ADD (&REST X) (DECLARE (DYNAMIC-EXTENT X)) (APPLY #'+ X))
(ADD 1 2 3) => 6
I.e., useful way to declare that &REST lists have dynamic extent
- - - - - - - -
(DEFUN ZAP (X Y Z)
(DO ((L (LIST X Y Z) (CDR L)))
((NULL L))
(DECLARE (DYNAMIC-EXTENT L))
(PRIN1 (CAR L))))
(ZAP 1 2 3)
prints 123
- - - - - - - -
(DEFUN ZAP (N M)
;; Computes (RANDOM (+ M 1)) at relative speed of roughly O(N).
;; It may be slow, but with a good compiler at least it
;; doesn't waste much heap storage. :-)
(LET ((A (MAKE-ARRAY N)))
(DECLARE (DYNAMIC-EXTENT A))
(DOTIMES (I N)
(DECLARE (DYNAMIC-EXTENT I))
(SETF (AREF A I) (RANDOM (+ I 1))))
(AREF A M)))
(< (ZAP 5 3) 3) => T
- - - - - - - -
The following are in error, since the value of X is used outside of its
extent:
(LENGTH (LIST (LET ((X (LIST 1 2 3))) (DECLARE (DYNAMIC-EXTENT X)) X)))
(PROGN (LET ((X (LIST 1 2 3))) (DECLARE (DYNAMIC-EXTENT X)) X)
NIL)
- - - - - - - -
Rationale:
This permits a programmer to offer advice to an implementation about
what may be stack-allocated for efficiency.
It may be difficult or impossible for a compiler to infer this
same information statically.
Since a number of implementations offer this capability and there
is demand from users for access to the capability, this ``codifies
existing practice.''
Because this approach is purely lexical, it does not interact badly with
other programs in the way that the macro WITH-DYNAMIC-EXTENT (see issue
by same name) would.
Current Practice:
Symbolics Genera and Symbolics Cloe offer stack allocation, though not
in this strategy.
[KMP thinks that] Lucid supports the proposal.
Cost to Implementors:
No cost is forced since implementations are permitted to simply
ignore the DYNAMIC-EXTENT declaration.
Cost to Users:
None. This change is upward compatible.
There may be some hidden costs to debugging using this declaration (or any
feature which permits the user to access dynamic extent objects without
the compiler proving that they are appropriate). If the user misdeclares
something and returns a pointer into the stack (or stores it in the heap),
an undefined situation may result and the integrity of the Lisp storage
mechanism may be compromised. Debugging these situations may be tricky,
but users who have asked for this feature have indicated a willingness
to deal with such costs. Nevertheless, the perils should be clearly
documented and casual users should not be encouraged to use this
declaration.
Cost of Non-Adoption:
Some portable code would be forced to run more slowly (due to
GC overhead), or to use non-portable language features.
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
This declaration allows a fairly low level optimization to work
by asking the user to provide only very high level information.
The alternatives (sharpsign conditionals, some of which may
lead to more bit-picky abstractions) are far less aesthetic.
Discussion:
A previous version of this proposal suggested primitives STACK-LET
and STACK-LET*. Consensus was that the more general declaration facility
would be more popular.
Pitman supports the DYNAMIC-EXTENT:NEW-DECLARATION.
Actually, a blurry issue is whether
(LENGTH (LIST (LET ((X (LIST 1 2 3))) (DECLARE (DYNAMIC-EXTENT X)) X)))
=> 1
is well-defined. I refer to these stack-allocated things as being invalid
return values, but in fact we might want to say that they're ok to return
but that you just can't do any serious operations on them (ie, you can't
expect them to still be lists, etc.) Can anyone imagine a pointer into
unallocated stack causing problems for their GC? If so, we could be more
clear on this point.
The examples are tricky:
"I hope no one misreads the above as an argument that my proposal is too
complicated, since it does not derive at all from my proposal, but only
from the way Common Lisp works."
!
Additional comments:
... I really like this rewrite a lot. It's quite
clever in the way it presents things in order to get additional flexibility.
However, I do have a few comments I'd like to see addressed before this
gets to a vote...
* I like the concept "proper part" a lot but I don't like the name.
The term "proper" for proper lists has to do with well-formed-ness
and in this context you're suggesting an incompatible meaning which
is confusing.
I suggest instead a term like "internal", "intrinsic", "private",
"unshared", etc.
[The concept of "unshared" makes me immediately scared about the
whole quote-may-copy morass, but I don't have time to think through
right now whether that's an issue that needs further clarification
or if it's just a red herring.]
* I like the concept of "saved" but it has the problem that it isn't
easy to bring up "out of context" since "save" has a lot of connotations.
If it were possible to come up with a more unique term, I think it
would help in lunch table conversations when people start getting
screwed by things that were `unintentionally saved' and others can't
figure out what they mean out of context.
* I think your list of definitions for saved is pretty good, but I'd
still like to see an abstract definition, and then the concrete cases
listed beneath it. That way, we are protected from weird unintentional
interpretations if someone discovers that the set was not exhaustive
and needs to include their new case under the abstract description
because the concrete list doesn't accomodate things.
* What about things like:
(DEFUN FOO (&REST X)
(DECLARE (DYNAMIC-EXTENT X))
(MAPL #'PRINT X)
T)
Genera's Dynamic Windows (DW) had bugs in its first release because the
window history recorded the object which was printed. Put another
way, PRINT did unexpected "saving" on some streams. The situation with
DW was treated as a bug and now DW correctly detects stack-allocated
things and does not try to save them, so this would work now.
However, it still raises the question of whether we should define
per-function for every CL function whether any of the arguments is
permitted to be "saved" so that CL programs don't get any funny surprises.
If we don't, it ends up being implementor's discretion how to resolve
cases like this, and everyone might not agree that all cases are as
obvious as this one was.
- - - - - - -
re: However, it still raises the question of whether we should define
per-function for every CL function whether any of the arguments is
permitted to be "saved" so that CL programs don't get any funny surprises.
If we don't, it ends up being implementor's discretion how to resolve
cases like this, and everyone might not agree that all cases are as
obvious as this one was.
PDP10 MacLisp had a similar problem w.r.t pdlnums. That is why
"identity" functions were so troublsome for it -- in order to
return a guaranteed safe value, it typically had to copy it's
pdlnum argument, thereby making some cases of "fast arithmetic"
code much worse than interpreted code! [Remember PRINT in MacLisp?
it returns T rather than it's argument for just this reason.]
It is necessary for an optimizing compiler to know something about
what happens to the data it passes along to "system" functions; for
example, it could assume that GET doesn't clobber the list given
to it, nor does it retain pointers to any part of it [what was the
terminology in the revised proposal? "saved"? and "proper part"?]
The issue LISP-SYMBOL-REDEFINITION might help here, in that an
implementation's compilers could depend upon it's own internal
database. But it wouldn't hurt at all to have some of these
requirements "up front" in the standard.
∂16-Mar-89 1354 X3J13-mailer Issue: DYNAMIC-EXTENT
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 13:54:21 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Thu, 16 Mar 89 16:49:45 EST
Date: Thu, 16 Mar 89 16:50 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: DYNAMIC-EXTENT
To: masinter.pa@xerox.com
Cc: X3J13@sail.stanford.edu
In-Reply-To: <890316-120057-5042@Xerox>
Message-Id: <19890316215008.1.BARMAR@OCCAM.THINK.COM>
re: However, it still raises the question of whether we should define
per-function for every CL function whether any of the arguments is
permitted to be "saved" so that CL programs don't get any funny surprises.
If we don't, it ends up being implementor's discretion how to resolve
cases like this, and everyone might not agree that all cases are as
obvious as this one was.
...
It is necessary for an optimizing compiler to know something about
what happens to the data it passes along to "system" functions; for
example, it could assume that GET doesn't clobber the list given
to it, nor does it retain pointers to any part of it [what was the
terminology in the revised proposal? "saved"? and "proper part"?]
The issue LISP-SYMBOL-REDEFINITION might help here, in that an
implementation's compilers could depend upon it's own internal
database. But it wouldn't hurt at all to have some of these
requirements "up front" in the standard.
I don't think that solves the problem. Yes, in a system where PRINT
saves its argument the compiler could detect that in
(defun print-em (&rest stuff)
(declare (dynamic-extent stuff))
(print stuff))
the declaration is obviously in error and may be ignored (or it might
generate a warning). In the case of Genera Dynamic Windows, whether
PRINT saves is actually an attribute of the stream, so it is
questionable whether the compiler should override the declaration
(perhaps the programmer knows that the function will only be called with
*STANDARD-OUTPUT* bound to a non-saving stream). Also, what about the
function
(defun process-em (&rest stuff)
(declare (dynamic-extent stuff))
(frobnicate stuff))
If FROBNICATE hasn't been written yet the compiler has no way of
knowing whether it calls any system functions that save the argument.
I think that if we really want this declaration (and I'd like to see it
included, as it is the right compromise for a long-standing problem) we
MUST say something about passing dynamic data to standard functions. I
think it would be sufficient to say that if the standard doesn't specify
that an argument must be saved then a dynamic object must be acceptable.
In other words, if a user reading the standard can't infer that an
argument will be saved then a conforming program may pass dynamic data
in that argument. This means that PRINT must accept a dynamic object,
and it is the implementation's responsibility to solve the potential
problems if it normally saves what PRINT prints.
barmar
∂16-Mar-89 1356 CL-Compiler-mailer Issue SAFE-CODE, version 1
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 13:56:46 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558883; Thu 16-Mar-89 16:53:42 EST
Date: Thu, 16 Mar 89 16:53 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue SAFE-CODE, version 1
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>, masinter.pa@Xerox.COM
cc: cl-compiler@SAIL.Stanford.EDU, x3j13@SAIL.Stanford.EDU
In-Reply-To: <svXEG@SAIL.Stanford.EDU>,
<890316-070317-3708@Xerox>,
<1avs40@SAIL.Stanford.EDU>,
<19890314214907.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890316215335.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Either "nonsafe code" or "code not declared safe" has better connotations
for me than "unsafe code." I don't really want to get too deeply involved
in choosing the terminology here (if I did, I would be on the editorial
committee), I only wanted to point out that the word used in version 1
of the proposal had an unwanted connotation for me.
∂16-Mar-89 1418 X3J13-mailer Issue DYNAMIC-EXTENT: a remark
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 14:18:09 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558915; Thu 16-Mar-89 17:15:26 EST
Date: Thu, 16 Mar 89 17:15 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue DYNAMIC-EXTENT: a remark
To: Guy Steele <gls@Think.COM>
cc: masinter.pa@xerox.com, X3J13@sail.stanford.edu
In-Reply-To: <8903162034.AA05881@verdi.think.com>
Message-ID: <19890316221519.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Thu, 16 Mar 89 15:34:53 EST
From: Guy Steele <gls@Think.COM>
A "proper
part" of an object A is any object that is accessible at the beginning
of the scope of the declaration -only- by applying a function to A or to
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
a "proper part" of A. This means that any objects freshly allocated
during the construction of the initial value of the declared variable,
and not "saved" during the construction of that value, are "proper
parts" and can be allocated on a stack.
I believe that the words indicated above should be replaced by
"the extent of the binding for which the delaration was made".
That would change the meaning, since the declaration might not be attached
to a binding.
The reference appears to be to a point in time. Scopes are in space;
the beginning of a scope is a character position in the text (or
something like that). Extents are in time. Is this what you meant?
You're right that there is something wrong with this wording. How about
if it said "at the beginning of execution of the forms in the scope of
the declaration"? Do declarations have extents? If so, could it say
"at the beginning of the extent of the declaration"?
∂16-Mar-89 1424 X3J13-mailer Issue: TIME-ZONE-NON-INTEGER, v.1
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 14:23:49 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558923; Thu 16-Mar-89 17:20:36 EST
Date: Thu, 16 Mar 89 17:20 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TIME-ZONE-NON-INTEGER, v.1
To: barmar@Think.COM
cc: Guy Steele <gls@Think.COM>, masinter.pa@xerox.com, x3J13@sail.stanford.edu
In-Reply-To: <8903161939.AA05061@verdi.think.com>
Message-ID: <19890316222034.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Thu, 16 Mar 89 14:39:11 EST
From: Guy Steele <gls@Think.COM>
Date: Thu, 16 Mar 89 12:16 EST
From: Barry Margolin <barmar@Think.COM>
Date: 16 Mar 89 07:07 PST
From: masinter.pa@xerox.com
Proposal (TIME-ZONE-NON-INTEGER:ALLOW)
Specify that the time zone part of Decoded Time is a rational number
(either an integer or a ratio).
Just to show you, when I become a billionaire I'll form my own country
and give it an irrational time zone (e in the winter, sqrt(2) in the
summer).
When you become a billionaire, you'll probably find that
you get a better approximation to e or sqrt(2) with a moby
bignum rational than with a float.
As a billionaire, you'll be able to afford to do all your processing
with indefinite-precision exact arithmetic.
Does Guy have inside information on when Barry will become a billionaire?
∂16-Mar-89 1436 X3J13-mailer Fatal vesus Harmless
To: x3j13@SAIL.Stanford.EDU
CC: cl-editorial@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
This is my last attempt at making my argument. I don't think there is much
else I can say to persuade you.
I wrote:
``The definition of fatal puts no time constraints on the fatality. Therefore,
neither does its negation.''
Let's define the term ``win'' to mean ``doesn't crash or abnormally
terminate''; basically, it is the bad case that the definition of
``fatal'' talks about. Let ``lose'' mean ``not win.''
Here are two partially formal definitions of ``fatal'' and ``harmless.''
The program P has consequences that are fatal if there
exists a sequence of conforming programs, P1,...,Pj,Pj+1,...,Pn, where
(progn P1...Pn) wins, but (progn P1...Pj P Pj+1...Pn) loses.
That is, the execution of P eventually leads to fatality in some program.
The program P has consequences that are harmless if
for all sequences of conforming programs, P1,...,Pj,Pj+1,...,Pn, where
(progn P1...Pn) wins, (progn P1...Pj P Pj+1...Pn) also wins.
That is, the execution of P never leads to fatality in any program.
There might be an infinite amount of hair to make this precise, but that's
the idea. And, there is some question about how different we allow the
behavior of the programs with P to be from the behavior of the programs
without P. (The language of the definitions of these terms are meant to
warn people to beware that behavior is in jeopardy.) But, the terms are
related by a negation with respect to the degree to which they are
well-defined.
I think part of the problem of understanding comes from the question of
side effects noticeable to conforming programs. A program with harmless
consequences can have side effects; notice our partly formal definition
doesn't say anything about what the programs do.
We all believe harmless a garbage collector that moves objects from place
to place where the movement is unnoticeable by conforming programs. Probably
most of us believe harmless a garbage collector whose progress is displayed.
I think none of us believes harmless a garbage collector that sets to
NIL all property lists of symbols in the USER package.
I think most of use believe harmful a garbage collector that changes the
order of properties on property lists.
However, consider an implementation of Common Lisp that uses a very hairy
representation for property-list lists. These lists have the feature that
sometimes the garbage collector will re-order their properties according
to some LRU bits to aid performance. Of course, through extreme hair, the
GC won't change the order if some piece of the property list is stored
somewhere other than the property list itself. Think of it as an
optimization that is conservatively performed.
Nowhere does the CL specification state that the order of properties
remains constant if the property list is not explicitly altered. Do those
of us who believed harmful the GC that changed property list order believe
this GC harmful? Or did some of us change our votes?
Suppose we alter the definition of symbol-plist from this:
``This returns *the* list the contains the property pairs of <symbol>;
the contents of the property-list cell are *extracted* and returned.''
to this:
``This returns *a* list the contains the property pairs of <symbol>;
the contents of the property-list cell are *copied* and returned.''
Now does the order-changing GC seem more harmless? It certainly has
less transparent behavior.
Suppose we explicitly specified that the order of properties on a property
list could change from time to time, possibly by GC actions. We have
defined the GC to be non-transparent, but is it harmless?
The sense of the definitions come from the partially formal definitions.
I think these definitions are pesuasive regarding the usefulness of a
term like ``harmless.''
I believe those definitions are difficult to make formal without some
very detailed computational or semantic model. The series of strange
GC behaviors with respect to property lists should make us leery of
making these definitions too precise at the expense of deciding these
cases one way when in five years we will wish we could decide them
the other way.
Specifications such as the one we are writing are communications
among people, and therefore absolute precision is impossible without
overspecification.
-rpg-
∂16-Mar-89 1443 CL-Compiler-mailer Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 14:43:02 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558959; Thu 16-Mar-89 17:39:16 EST
Date: Thu, 16 Mar 89 17:39 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
To: Barry Margolin <barmar@FAFNIR.THINK.COM>
cc: masinter.pa@xerox.com, cl-compiler@sail.stanford.edu, X3J13@sail.stanford.edu
In-Reply-To: <19890316173142.7.BARMAR@OCCAM.THINK.COM>
Message-ID: <19890316223916.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Thu, 16 Mar 89 12:31 EST
From: Barry Margolin <barmar@FAFNIR.THINK.COM>
I'll just reiterate something I said at one of the meetings. One
portable use I can think of for the COMPILED-FUNCTION type is as a
declaration to allow compiler optimization. If a function knows (or
requires) that a parameter is a compiled function it can declare that
and the implementation may be able to optimize the FUNCALL better.
But as someone said the last time this suggestion was brought up, if
there is no portable meaning of the COMPILED-FUNCTION type and no
portable way to create an object of that type, no useful correct program
can contain this declaration.
Another thing I just thought of is something like:
(when (typep f '(and function (not compiled-function)))
(setq f (compile nil f)))
This doesn't actually work because COMPILE isn't required to accept
lexical closures
You just glimpsed the tip of the iceberg.
∂16-Mar-89 1551 X3J13-mailer Issue: COERCE-INCOMPLETE (Version 3)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 15:51:26 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Thu, 16 Mar 89 17:59:11 EST
Date: Thu, 16 Mar 89 18:00 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: COERCE-INCOMPLETE (Version 3)
To: masinter.pa@xerox.com
Cc: x3j13@sail.stanford.edu
In-Reply-To: <890316-095901-4371@Xerox>
Message-Id: <19890316230020.6.BARMAR@OCCAM.THINK.COM>
There's an inconsistency in the names of the proposals. In the Proposal
sections, the two proposals are named LIMITED-ARBITRARY-EXTENSION and
DEPRECATE. But in some other sections they are called COERCE and
DEPRECATE.
Problem with DEPRECATE: Didn't we specify that the way to convert a
lambda expression into a function object is to use (COERCE x 'FUNCTION)?
Or did we also define a new function that does this?
barmar
∂16-Mar-89 1603 X3J13-mailer *DRAFT* Issue: DESTRUCTURING-BIND, v.2
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 16:02:40 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Thu, 16 Mar 89 17:45:15 EST
Date: Thu, 16 Mar 89 17:46 EST
From: Barry Margolin <barmar@Think.COM>
Subject: *DRAFT* Issue: DESTRUCTURING-BIND, v.2
To: masinter.pa@xerox.com
Cc: X3J13@sail.stanford.edu
In-Reply-To: <890316-114911-4982@Xerox>
Message-Id: <19890316224608.4.BARMAR@OCCAM.THINK.COM>
Date: 16 Mar 89 11:46 PST
From: masinter.pa@xerox.com
Current Practice:
The DESTRUCTURING-BIND offered by Symbolics Genera signals an error if
the pattern is not matched. The TI Explorer version does not.
Actually, Genera offers TWO versions of DESTRUCTURING-BIND:
SYMBOLICS-COMMON-LISP:DESTRUCTURING-BIND and
ZETALISP:DESTRUCTURING-BIND. The former signals an error, while the
latter does not (it's probably very similar to the Explorer version,
since they are genetically closer).
barmar
∂16-Mar-89 1726 X3J13-mailer Issue: MAKE-STRING-FILL-POINTER (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 17:25:54 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 16:55:22 PST
Date: 16 Mar 89 16:49 PST
From: masinter.pa@Xerox.COM
Subject: Issue: MAKE-STRING-FILL-POINTER (Version 1)
to: X3J13@sail.stanford.edu
line-fold: NO
Message-ID: <890316-165522-6151@Xerox>
The discussion on this issue pointed out that it would
extend the range of MAKE-STRING so that it was no
longer restricted to return a SIMPLE-STRING, which
might break some type-inference.
!
Issue: MAKE-STRING-FILL-POINTER
References: CLtL p.302
Related issues: none that I know of
Category: ADDITION
Edit history: Version 1, 20-Oct-88, by Moon, for discussion
Problem description:
Once again I lost because I expected to be able to use MAKE-STRING
to create a string with a fill-pointer, and I couldn't. I had to use
a more long-winded MAKE-ARRAY call instead.
Proposal (MAKE-STRING-FILL-POINTER:ALLOW):
Give MAKE-STRING a :FILL-POINTER argument, with the same syntax and
semantics as the :FILL-POINTER argument to MAKE-ARRAY.
Examples:
(make-string 80 :fill-pointer 0)
Test Cases:
See examples.
Rationale:
I frequently expect it to be allowed and am surprised when it's not.
Current practice:
I know of no implementations that support this.
Cost to Implementors:
5 cents.
Cost to Users:
none
Cost of non-adoption:
none
Performance impact:
none
Benefits:
Increased language consistency.
Esthetics:
Increased language consistency.
Discussion:
Other MAKE-ARRAY options that one might want to allow, but are
not already allowed or proposed, are :INITIAL-CONTENTS, :ADJUSTABLE,
:DISPLACED-TO, and :DISPLACED-INDEX-OFFSET. A strong case could be
made for :ADJUSTABLE (I use an implementation where it doesn't matter,
so I don't care about that), I don't think anyone would care about the
other three.
∂16-Mar-89 1745 X3J13-mailer Issue: EXTRA-RETURN-VALUES
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 16 Mar 89 17:45:24 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA18011; Thu, 16 Mar 89 00:34:36 PST
Message-Id: <8903160834.AA18011@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for x3j13@sail.stanford.edu; id AA18011; Thu, 16 Mar 89 00:34:36 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 16 Mar 89 03:24
To: x3j13@sail.stanford.edu
Subject: Issue: EXTRA-RETURN-VALUES
Issue: EXTRA-RETURN-VALUES
References: Chapter 1, Section 1.5, Working draft of standard
Category: Clarification
Edit history: 8-JAN-89, Version 1 by Masinter
3-FEB-89, Version 2 by Chapman
10-MAR-89, Version 3 by Chapman
Problem: Is it OK to return extra values from Common Lisp functions?
Proposal: EXTRA-RETURN-VALUES:NO
A function that is specified by the standard must return EXACTLY the number
of return values specified by the standard.
Rationale:
The reason is that
additional arguments are visible to otherwise portable programs. For
instance, (multiple-value-call #'cons (floor x y)) looks portable, but it
will try to pass the wrong number of arguments to CONS if FLOOR returns an
extra value.
Current Practice:
At least one implementation returns extra values for certain functions
not currently specified to return those values.
Adoption Cost:
Implementations and their associated documentation that now contain
functions that return extra values will have to change.
Benefits:
Programs will potentially become more portable.
Conversion Cost:
See Adoption Cost.
Aesthetics:
None.
Discussion:
∂16-Mar-89 1746 X3J13-mailer Issue: COERCE-INCOMPLETE (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 17:45:59 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 559088; Thu 16-Mar-89 19:18:34 EST
Date: Thu, 16 Mar 89 19:18 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COERCE-INCOMPLETE (Version 3)
To: barmar@Think.COM
cc: masinter.pa@xerox.com, x3j13@sail.stanford.edu
In-Reply-To: <19890316230020.6.BARMAR@OCCAM.THINK.COM>
Message-ID: <890316191820.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Thu, 16 Mar 89 18:00 EST
From: Barry Margolin <barmar@Think.COM>
...
Problem with DEPRECATE: Didn't we specify that the way to convert a
lambda expression into a function object is to use (COERCE x 'FUNCTION)?
Or did we also define a new function that does this?
Re-read FUNCTION-TYPE. The thing Beckerle really wanted and finally
got (over my objection) was that COERCE did nothing `hard' ... What
it ended up being able to be do can be expressed by #'IDENTITY and
#'SYMBOL-FUNCTION.
(COERCE x 'FUNCTION) ==
(ETYPECASE X
(SYMBOL (SYMBOL-VALUE X))
(FUNCTION X))
I don't really think anything more needs to be provided, even if we
DEPRECATE coerce.
∂16-Mar-89 1801 X3J13-mailer SYMBOL-MACROLET-SEMANTICS, version 6
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 18:01:42 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 17:46:06 PST
Date: 16 Mar 89 17:44 PST
From: masinter.pa@Xerox.COM
To: x3j13@sail.stanford.edu
Subject: SYMBOL-MACROLET-SEMANTICS, version 6
line-fold: NO
Message-ID: <890316-174606-6317@Xerox>
This is a proposal to amend version 5, passed in January 1989 in Kauai.
Version 6 amends version 5 to require PSETQ to behave like PSETF,
to require MULTIPLE-VALUE-SETQ to accept symbol macros (but not
general SETF places), and to specify the interaction with the
*MACROEXPAND-HOOK* function.
We would like to have the proposal reconsidered, and
accepted as amended.
!
Issue: SYMBOL-MACROLET-SEMANTICS
References: SYMBOL-MACROLET (88-002R page 2-81)
Related Issues: SYMBOL-MACROLET-DECLARE
Category: CHANGE
Edit history: 29-July-88, Version 1 by Piazza
21-September-88, Version 2 by Piazza
22-September-88, Version 3 by Piazza
22-September-88, Version 4 by Piazza
30-Nov-88, Version 5 by Masinter
14-Mar-89, Version 6 by Steele
Problem Description:
The SYMBOL-MACROLET construct, introduced with CLOS in X3J13 document
88-002R, profoundly alters the interpretation of symbols appearing as
forms in a Common Lisp program--what previously was necessarily a variable
might now be a symbol macro instead. Macros which appear in the body of a
SYMBOL-MACROLET form are currently unable to determine whether a symbol
form is a variable or a symbol macro, and, if the latter, what the
expansion of the symbol macro is. Consequently, complex macros (such as
SETF or PUSH) which depend on the form of their argument(s), are unable to
produce their desired results in some cases, as in the following example:
(let ((a (make-array 5))
(i 0))
(symbol-macrolet ((place (aref a (incf i))))
(push x place))
i) ==> 2
In addition, it would be both natural and nice to be able to write
(with-slots (rho theta) point
(declare (single-float rho theta))
...computation...)
as well as DECLARE within SYMBOL-MACROLET forms.
Proposal (SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM):
Change the definition of SYMBOL-MACROLET to specify that it is a special
form, which affects the evaluation environment for symbols. Enhance
MACROEXPAND and MACROEXPAND-1 so that they can expand a symbol macro.
Modify SETF et al to use the new MACROEXPAND and MACROEXPAND-1 to examine
even symbol subforms. Specify that the expansion of a symbol macro IS
subject to further macro expansion in the same lexical environment as the
symbol macro invocation, exactly analogous to normal macros. Clarify that
within the body of a SYMBOL-MACROLET, SETQ of a symbol defined as
a symbol macro will be treated as if it were a SETF.
Furthermore PSETQ of a symbol defined as a symbol macro will
behave as if it were a PSETF, and MULTIPLE-VALUE-SETQ will behave
as if SETQ were used on each variable to be set.
When MACROEXPAND or MACROEXPAND-1 sees a symbol macro, it calls
the value of *MACROEXPAND-HOOK* in the same manner as for an
ordinary macro. The three values given to the hook function
in this case will be an expansion function, a form (in this case
the symbol naming the symbol macro), and an environment. The
only guaranteed property of the expansion function is that when
it is applied to the form and the environment it will return the
correct expansion of the symbol macro. (In particular, nothing
it said in this specification whether the expansion is conceptually
stored in the expansion function, the environment, or both.)
Rationale:
The potential for interaction between macros is exactly why &environment
arguments were originally added to macros. Changing SYMBOL-MACROLET to be
a special form, which communicates through the &environment arguments to
macros with MACROEXPAND and MACROEXPAND-1, would allow PUSH and SETF
(among others) to work with SYMBOL-MACROLET in the same way they work with
MACROLET.
This change cannot (reasonably) support the currently specified semantics
that the expansion text is "outside" the scope of the symbol macro. For
indeed, when the symbol macro is expanded, (a copy of) the expansion is
then within the scope of the SYMBOL-MACROLET, and should then be subject
to further scrutiny. The issue of "infinite expansion" of symbol macros is
no more dangerous than that of normal macros.
Current Practice:
Portable Common Loops provides a code-walking implementation of
SYMBOL-MACROLET as specified in 88-002R. Symbolics Cloe has both a
code-walking version of a SYMBOL-MACROLET macro and compiler support for
a SYMBOL-MACROLET special form.
Cost to Implementors:
If SYMBOL-MACROLET is modified to be a special form, compilers and
interpreters will have to change, as well as MACROEXPAND, MACROEXPAND-1,
PUSH, INCF, DECF, and others.
Cost to Users:
If SYMBOL-MACROLET is converted to a special form, code-walking programs
will have to be modified to handle SYMBOL-MACROLET correctly. Those same
programs would have to be modified to handle the other special forms
specified in CLOS, anyway.
Cost of Non-Adoption:
SYMBOL-MACROLET will retain its confusing semantics, leading to bugs when
it interacts with complex macros and forms which produce side-effects.
Implementations which support ONCE-ONLY will break. For that matter, any
mechanism which examines code and assumes that "variables" have no side
effects will break.
Benefits:
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM avoids the hairiest problems
surrounding interaction of macros (like SETF) and side effects, and makes
SYMBOL-MACROLET consistent with MACROLET.
Aesthetics:
If SYMBOL-MACROLET is made to be a special form, aesthetics are improved
by making symbol macros consistent with normal macros.
Discussion:
A case could be made for adding a new function, SYMBOL-MACRO-FUNCTION, as
a dual of MACRO-FUNCTION. However, symbol macros are simpler than normal
macros: a symbol macro is associated with a single expansion form, rather
than an arbitrary function which computes the expansion. For this reason,
the augmented MACROEXPAND-1 proposed here can also fill the role of
SYMBOL-MACRO-FUNCTION: the second value of (macroexpand-1 sym env) will be
T if and only if sym is a symbol macro, while the first value gives the
expansion of sym, if it has one.
Rather than extending the existing MACROEXPAND and MACROEXPAND-1
functions, new functions could be introduced to expand symbol macros.
However, there seems to be no particular reason to do this.
∂16-Mar-89 2103 X3J13-mailer Issue: EXIT-EXTENT, v.6
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 21:03:05 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 21:00:49 PST
Date: 16 Mar 89 20:52 PST
From: masinter.pa@Xerox.COM
Subject: Issue: EXIT-EXTENT, v.6
to: X3J13@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: NO
Message-ID: <890316-210049-6699@Xerox>
This version was distributed in hardcopy form at the
January 1989 meeting, but was tabled.
There are two proposals.
!
Issue: EXIT-EXTENT
References: CATCH, THROW (p 142),
BLOCK, RETURN, RETURN-FROM,
TAGBODY, GO, UNWIND-PROTECT,
Dynamic extent (CLtL p.37),
Nested dynamic extents (CLtL p.38),
Blocks can only be exited once (CLtL p.120),
Catch is disestablished just before the values
are returned (CLtL p.139).
Related issues: UNWIND-PROTECT-NON-LOCAL-EXIT is superseded
by this one.
Category: CLARIFICATION
Edit history: ... Version 5 of UNWIND-PROTECT-NON-LOCAL-EXIT, 23-May-88 ...
Version 1, 5-Sep-88, by Moon, for discussion
Version 2, 1-Oct-88, by Masinter, minor edits
Version 3, 7-Oct-88, by Moon, wording improvements
Version 4, 7-Dec-88, by Masinter, add MEDIUM from
UNWIND-PROTECT-NON-LOCAL-EXIT, discussion.
Version 5, 12-Dec-88, Masinter, clarify MINIMAL allows MEDIUM
Version 6, 8-Jan-89, Masinter, fix some bugs
Problem description:
CLtL does not specify precisely when the dynamic extent (lifetime)
of a nonlocal exit such as a CATCH, BLOCK, or TAGBODY ends.
For example, at what point is it no longer possible to RETURN-FROM
a particular BLOCK?
An "exit" refers to a point from which control can be transferred.
For a THROW or RETURN-FROM, the "exit" is the corresponding CATCH
or BLOCK body. For a GO, the "exit" is the form within the TAGBODY
which was being executed at the time the GO is performed.
The extent of an exit is dynamic; it is not indefinite. The extent
of an exit begins when the corresponding form (CATCH, BLOCK or TAGBODY
clause) is entered. When the extent of an exit has ended, it is no
longer legal to return from it.
The extent of an exit is not the same thing as the scope of the
designator by which the exit is identified. For example, a BLOCK
name has lexical scope but the extent of its exit is dynamic; the
scope of a CATCH tag could differ from the extent of the CATCH's
return point. (That's part of what is at issue here.)
The ambiguity at issue arises for the case where there are transfers
of control from the cleanup clauses of an UNWIND-PROTECT.
When a transfer of control is initiated by GO, RETURN-FROM or THROW,
a variety of events occur before the transfer of control is complete.
In particular,
(a) the cleanup clauses of any intervening UNWIND-PROTECT clauses
are evaluated,
(b) intervening dynamic bindings of special variables and catch tags
are undone,
(c) intervening exits are "abandoned", i.e., their extent ends and it
is no longer legal to attempt to transfer control through them,
(d) the extent of the exit being invoked ends,
(e) control is finally passed to the target.
The order of these events is not explicit in CLtL, however. The
implementation note on p.142 gives a clue about the interweaving
of (a) and (b), but there are differing opinions about the times
at which (c) and (d) may occur. In particular,
Is it legal for an implementation to end the extent of all
intervening exits before processing the cleanup clauses of intervening
UNWIND-PROTECTs?
What is the dynamic context at the time UNWIND-PROTECT clauses are
evaluated: how is the unwinding of dynamic bindings intertwined with
evaluation of UNWIND-PROTECT cleanup clauses?
Proposal (EXIT-EXTENT:MINIMAL):
The extent of an exit--whether it is being "abandoned" because it is
being passed over, or it is itself the target exit--ends as soon as
the transfer of control is initiated. That is, the events (c) and (d)
at the beginning of the initiation of the transfer of control. In the
language of the implementation note on p.142, the extent ends at the
beginning of the second pass. It is an error to attempt a transfer
of control to an exit whose dynamic extent has ended.
Otherwise, events (a) and (b)--the undoing of dynamic binding of special
variables and CATCH tags, and the execution of UNWIND-PROTECT cleanup
clauses--are performed in the order corresponding to the reverse order
in which they were established, as implied by the implementation note
on p.142. The effect of this is that the cleanup clauses of an UNWIND-PROTECT
will see the same dynamic bindings of variables and CATCH tags as were
visible when the UNWIND-PROTECT was entered.
This proposal is called "minimal" because it gives exits the smallest
extent consistent with CLtL. A program that presumed a longer extent
would be in error. Implementations may support longer extents for
exits than is required by this proposal; in particular, an
implementation which allowed the larger extent of the MEDIUM
proposal below would still conform.
Proposal (EXIT-EXTENT:MEDIUM):
The events of (a), (b), (c) and (d) are interwoven in the reverse
order in which they were established. In particular, the extent of
a passed-over exit ends when control reaches a frame that was
established before the exit was established.
In particular, it is legal, during the evaluation of an UNWIND-PROTECT
cleanup form executed because of a non-local transfer of control, to
initiate a new transfer of control to an exit intervening between the
UNWIND-PROTECT and the original target; the original processing of
transfer of control is abandoned.
Examples:
;; Error under either proposal: BLOCK exits normally before RETURN
(funcall (block nil #'(lambda () (return))))
;; Error under either proposal: normal exit before GO
(let ((a nil))
(tagbody t (setq a #'(lambda () (go t))))
(funcall a))
;; Error under either proposal: TAGBODY is passed over, before GO
(funcall (block nil
(tagbody a (return #'(lambda () (go a))))))
;;returns 2 under MEDIUM, is error under MINIMAL
(block nil
(unwind-protect (return 1)
(return 2)))
;;returns 2 under MEDIUM, is error under MINIMAL
(block a
(block b
(unwind-protect (return-from a 1)
(return-from b 2))))
;; returns 2 under MEDIUM, is error under MINIMAL
(catch nil
(unwind-protect (throw nil 1)
(throw nil 2)))
;; returns 2 under MEDIUM, is error under MINIMAL
;; because the catch of B is passed over by
;; the first THROW, hence portable programs must assume its dynamic extent
;; is terminated. The binding of the catch tag is not yet disestablished
;; and therefore it is the target of the second throw.
(catch 'a
(catch 'b
(unwind-protect (throw 'a 1)
(throw 'b 2))))
;; the following is an error under MINIMAL; the extent of the
;; inner catch terminates as soon as the THROW commences, even
;; though it remains in scope. Thus, the THROW of :SECOND-THROW
;; sees the inner CATCH, but its extent has ended.
;; under MEDIUM, it prints "The inner catch returns :SECOND-THROW"
;; and then returns :OUTER-CATCH.
(catch 'foo
(format t "The inner catch returns ~s.~%"
(catch 'foo
(unwind-protect (throw 'foo :first-throw)
(throw 'foo :second-throw))))
:outer-catch))
;; Following returns 10 under either proposal. The inner
;; CATCH of A is passed over, but because that CATCH
;; is disestablished before the THROW to A is executed,
;; it isn't seen.
(catch 'a
(catch 'b
(unwind-protect (1+ (catch 'a (throw 'b 1)))
(throw 'a 10))))
;; Following is an error under MINIMAL because the extent of
;; the (CATCH 'FOO ...) exit ends when the (THROW 'FOO ...)
;; commences.
;; Under MEDIUM, the pending exit to tag FOO is discarded by the
;; second THROW to BAR and the value 4 is transferred to
;; (CATCH 'BAR ...), which returns 4. The (CATCH 'FOO ...)
;; then returns the 4 because its first argument has returned
;; normally. XXX is not printed.
(CATCH 'FOO
(CATCH 'BAR
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
(PRINT 'XXX))))
;; Following returns 4 under either proposal; XXX is not printed.
;; The (THROW 'FOO ...) has no effect on the scope of the BAR
;; catch tag or the extent of the (CATCH 'BAR ...) exit.
(CATCH 'BAR
(CATCH 'FOO
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
(PRINT 'XXX))))
;;The following are legal and print 5 under either proposal:
(block nil
(let ((x 5))
(declare (special x))
(unwind-protect (return)
(print x))))
(block nil
(let ((x 5))
(declare (special x))
(unwind-protect
(if (test) (return))
(print x))))
Rationale:
For MINIMAL: Giving exits the smallest extent consistent with CLtL
maximizes freedom for implementations; there are few applications,
if any, that require a longer extent.
For MEDIUM: Giving exits a longer extent has cleaner semantics.
Current practice:
Both implementations of Symbolics Genera (3600 and Ivory) end the extent
of a target BLOCK or CATCH at the moment the values are returned, and
end the extent of a passed-over exit at the moment the THROW, RETURN, or
GO commences. This choice of extent maximizes efficiency within the
particular stack structure used by these implementations, by avoiding
the need to retain the control information needed to use a passed over
exit through the transfer of control. Genera signals an error if an
attempt is made to use an exit that has been passed over.
In some implementations, it is possible for a throw or non-local exit
to be effectively "stopped" by an UNWIND-PROTECT cleanup clause that
performs a non-local transfer of control to a passed-over exit.
Some implementations crash or otherwise generate garbage code for
non-local exits from cleanup clauses of UNWIND-PROTECT.
Cost to Implementors:
No currently valid implementation will be made invalid by the MINIMAL
proposal. Some implementors may wish to add error checks if they
do not already have them.
MEDIUM would have a high cost for those implementations that currently
have shorter extent.
Cost to Users:
Most user programs don't do this, so there is likely little cost
of converting existing code in any case. In any case, current implementations
differ enough that this issue ostensibly does not
affect current portable programs. Some users might have code that
relies on the "unstoppable loops" that can be created with the MEDIUM
proposal.
Benefits:
Either proposal would make Common Lisp more precisely defined.
Cost of non-adoption :
The semantics of exits will remain ambiguous.
Esthetics:
Precisely specifying the meaning of dynamic extent improves the language.
Leaving implementations free to implement a longer extent if they choose
can be regarded as unesthetic, but consistent with Common Lisp philosophy.
Having a CATCH that is in scope even though its extent has ended may
seem unesthetic, but it is consistent with how BLOCK behaves.
Discussion:
This issue is controversial. It was first discussed under the issue
named UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT. The issue was recast as
the more global one of "extent of exits" rather than the specific
one of "what happens if a cleanup in an UNWIND-PROTECT does a non-
local exit", but the problem cases for both topics are the same.
The goal of the MINIMAL proposal is to clarify the ambiguity in CLtL while
minimizing changes to the current situation. The MEDIUM proposal
defines the extent of an exit to end at the last moment possible
within some particular reference implementation. It has
a cost to implementors whose implementation is not identical to the
reference implementation. Another alternative proposal, not considered
here, would duck the issue by outlawing all non-local exits from UNWIND-PROTECT
cleanup forms. That alternative would have a substantial cost to some users.
Scheme is cleaner: it avoids this issue by specifying that the extent
of an exit never ends.
An argument for the MEDIUM proposal was made based on the example:
(block foo
(block bar
(unwind-protect
(return-from foo 'foo)
(return-from bar 'bar))))
Since there is no reason for FOO and BAR not to be treated interchangeably,
calling this an error would be inappropriate.
It was argued that the MINIMAL proposal is equivalent to practically
outlawing non-local exits from UNWIND-PROTECT cleanup clauses, because
there is no general way to determine the target of the non-local exit
that caused the cleanup clause to be invoked.
The following example was offered as an argument against MINIMAL. Given:
(block nil
(handler-case
(unwind-protect (return)
(error "foo")) ;probably an error, under the proposal
(error ()
(print "foo"))))
If the ERROR handler has the same scope and extent a CATCH in the same place
would have (and that seems reasonable, though I'm not certain that the
condition system specifically requires that interpretation), then the handler
will be apparent to the call to ERROR, but will no longer be a valid target
(its extent was exited by the RETURN in the UNWIND-PROTECT body).
The extent of an object with dynamic extent is the extent of the form
which created it. Code which is executed "within" that form is within
the extent of the object(s). This applies to all dynamic objects, such
as special variable bindings, not just exits. Actually, I think the intent
of the implementation note on p.142 is fairly clear and supports this
interpretation. The supposedly ambiguous use of "frame" should be read
as something like "form which establishes a dynamic extent". It might be
clearer if the last sentence were changed to read something like:
"On the second pass the stack is actually unwound. Each form which establishes
a dynamic extent is undone in reverse order of creation until the matching
CATCH is reached. The meaning of undoing a form depends on the type of form.
For UNWIND-PROTECT, it means executing the cleanup forms. For CATCH it means
removing the CATCH tag. For dynamic bindings it means undoing the binding,
restoring the previous saved value. {This is not an exhaustive listing of the
possibilities.}"
----- End Forwarded Messages -----
∂16-Mar-89 2220 X3J13-mailer Issue: FUNCTION-COERCE-TIME (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 22:20:17 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 22:18:04 PST
Date: 16 Mar 89 22:17 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-COERCE-TIME (Version 2)
From: cl-cleanup@sail.stanford.edu
To: x3j13@sail.stanford.edu
REPLY-TO: cl-cleanup@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <890316-221804-6820@Xerox>
Unfortunately, there have been no new versions of this
produced since it was last distributed, labelled DRAFT, to X3J13
prior to the October, 1988 meeting in Fairfax.
Excerpts from the mail on this are appended.
!
Issue: FUNCTION-COERCE-TIME
References: SET-MACRO-CHARACTER (p362),
SET-DISPATCH-MACRO-CHARACTER (p364),
MAP (p249), MAPL (p129), ...
Functions using :TEST, :KEY, etc. (REDUCE, MEMBER, DELETE, ...)
Functions using a positional predicate (SORT, DELETE-IF, ...)
Category: CLARIFICATION
Edit history: 20-Jun-88, Version 1 by Pitman
16-Sep-88, Version 2 by Pitman
(changes to presentation of all proposals per Masinter's comments)
Status: For Internal Discussion
Problem Description:
Many functions which accept arguments which are to be treated functionally
but which are not of type FUNCTION. This functionality can be very useful,
but the time at which the coercion is accomplished must be made clear.
Proposal (FUNCTION-COERCE-TIME:LAZY):
Specify that when a non-function (eg, a symbol) is used as a functional
argument to an operator, the coercion of that non-function to a function
is delayed until the function is about to be called and is done anew
every time the function is to be called. That is, passing a non-function
functional argument, F, is equivalent to passing
#'(LAMBDA (&REST ARGUMENTS)
(APPLY F ARGUMENTS))
Rationale:
One of the main reasons that it may be useful to pass a non-function
instead of a function is to accomplish indirection which allows later
redefinitions to take proper effect. Early binding would tend to
thwart the usefulness of such indirection and force people into
notationally more clumsy devices.
Proposal (FUNCTION-COERCE-TIME:AMBITIOUS):
Specify that when a non-function (eg, a symbol) is used as a functional
argument to an operator, the coercion of that non-function to a function
is done immediately. That is, all such functions treat a non-function
functional argument, F, as if
(COERCE F 'FUNCTION)
had been passed instead.
Rationale:
This is easier to implement since the coercion is done up front and
no further worry about uncoerced functions is needed internally.
Also, inlining of mapped functions (without using temporary storage
to hold a cached value of the function being mapped) can be done
without needing to know whether the function being inlined will
affect the place which holds the functional argument being passed.
Proposal (FUNCTION-COERCE-TIME:HYBRID):
Specify that when a non-function (eg, a symbol) is used as a
functional argument to an operator, the coercion of that non-function
to a function must be done immediately if the functional argument is
to be used only internally to the function (eg, SORT or MAPCAR).
Otherwise, if the functional argument's use persists beyond the end
of the call to the operator (eg, SET-MACRO-CHARACTER), any coercion is
delayed until the function is about to be called and is done anew every
time the function is to be called.
That is, functions like SORT and MAPCAR are permitted to treat a
non-function functional argument, F, as if
(COERCE F 'FUNCTION)
had been passed instead. However, functions like SET-MACRO-CHARACTER
would treat a non-function functional argument, F, as if
#'(LAMBDA (&REST ARGUMENTS)
(APPLY F ARGUMENTS))
were passed instead.
Rationale:
Debugging is enhanced for operations such as SET-MACRO-CHARACTER
without needlessly hampering useful optimizations to things like
SORT or MAPCAR, which very rarely require this facility.
Test Cases:
(DEFVAR *SOME-FUNCTIONS*
(LIST #'(LAMBDA (X) (SETF (SYMBOL-FUNCTION 'FOO) X) 1)
#'(LAMBDA (X) (SETF (SYMBOL-FUNCTION 'FOO) X) 2)
#'(LAMBDA (X) (SETF (SYMBOL-FUNCTION 'FOO) X) 3)
#'(LAMBDA (X) (SETF (SYMBOL-FUNCTION 'FOO) X) 4)))
; Control situation A
(PROGN (SETF (SYMBOL-FUNCTION 'FOO) (CAR *SOME-FUNCTIONS*))
(LIST (MAPCAR #'(LAMBDA (&REST X) (APPLY #'FOO X))
*SOME-FUNCTIONS*)
(FOO T)))
=> ((1 1 2 3) 4)
; Control situation B
(LET ((FOO (SETF (SYMBOL-FUNCTION 'FOO) (CAR *SOME-FUNCTIONS*))))
(LIST (MAPCAR FOO
*SOME-FUNCTIONS*)
(FOO T)))
=> ((1 1 1 1) 4)
; Interesting Situation 1
(PROGN (SETF (SYMBOL-FUNCTION 'FOO) (CAR *SOME-FUNCTIONS*))
(LIST (MAPCAR #'FOO
*SOME-FUNCTIONS*)
(FOO T)))
=> ((1 1 2 3) 4) ;Lazy-1
or ((1 1 1 1) 4) ;Ambitious-1
; Interesting Situation 2
(PROGN (SETF (SYMBOL-FUNCTION 'FOO) (CAR *SOME-FUNCTIONS*))
(LIST (MAPCAR 'FOO
*SOME-FUNCTIONS*)
(FOO T)))
=> ((1 1 2 3) 4) ;Lazy-2
or ((1 1 1 1) 4) ;Ambitious-2
(DEFUN SHARP-DOLLAR (STREAM CHAR N)
(DECLARE (IGNORE CHAR))
(EXPT (READ STREAM) (OR N 1)))
(SET-DISPATCH-MACRO-CHARACTER #\# #\$ 'SHARP-DOLLAR)
(VALUES (READ-FROM-STRING "(#$3 #4$3)"))
=> (3 81)
(DEFUN SHARP-DOLLAR (STREAM CHAR N)
(DECLARE (IGNORE CHAR))
(+ (READ STREAM) (* (OR N 0) 0.01)))
(VALUES (READ-FROM-STRING "(#$3 #4$3)"))
=> (3.0 3.04) ;Lazy-3
(3 81) ;Ambitious-3
Proposal LAZY requires LAZY-1, LAZY-2, LAZY-3.
Proposal AMBITIOUS requires AMBITIOUS-1, AMBITIOUS-2, AMBITIOUS-3.
Proposal HYBRID requires AMBITIOUS-1, AMBITIOUS-2, LAZY-3.
Current Practice:
Implementations are permitted to differ in when they do the coercion since
the coercion time is not clearly spelled out.
(In the test case, LAZY-1 can occur only if MAPCAR is inlined, and then
only if the original value of the function definition is not cached.)
[Some info below is based on empirical testing -- I didn't look at the
source or try to see how speed/safety affect things. -kmp]
Symbolics Genera implements AMBITIOUS-1 interpreted and LAZY-1 compiled.
Symbolics Cloe (a compiled-only lisp) implements LAZY-1 both `interpreted'
and compiled.
Both Symbolics Genera and Symbolics Cloe implement LAZY-2.
Symbolics Genera implements LAZY-3.
Symbolics Cloe implements AMBITIOUS-3.
Cost to Implementors:
[Costs may vary widely depending on current practice.
I'll leave this one open for now pending feedback from others. -kmp]
Cost to Users:
This change is upward compatible.
Cost of Non-Adoption:
A very important aspect of the language would be left unspecified.
Portability would suffer.
Benefits:
HYBRID has the benefit of making things like readmacros easier to debug.
LAZY offers the additional benefit of being able to repair certain
functional arguments to SORT or MAPCAR (eg, as a symbol) in the debugger,
and then to proceed the error (in implementations offering that restart
option) in a way that makes the ongoing call to SORT or MAPCAR notice
the repairwork right away.
Aesthetics:
Since this is a visible aspect of the language, anything which clarified
the behavior that a programmer might expect would seem to improve the
aesthetics somewhat.
Discussion:
This issue was raised by Nick Gall and written up by Pitman.
Pitman supports FUNCTION-COERCE-TIME:HYBRID.
!
Additional comments:
There was some concern about the proposal wording, because
it was trying to allow for the possibility that implementations
might extend other objects (e.g., lists that begin with
LAMBDA) to "coerce" to functions, and the proposal should
apply for them, too.
This made the wording of the proposal pretty awkward, though.
- - - - - -
The writeup for the LAZY option should mention that this might cause a
substantial performance hit in some implementations.
Of the options presented, I prefer AMBITIOUS. However, I would really
much rather see this whole issue left explicitly vague in the
standard.
- - - -
notes from Cleanup meeting (Fairfax, 1988):
Eliminate the AMBITIOUS proposal. Continue to evolve the
HYBRID and LAZY variants.
Relation to DEBUG quality.
There was some discussion about the idea of permitting vagueness
(ie, making LAZY/AMBITIOUS optional in some places).
X3J13 meeting:
Some people weren't completely convinced that the HYBRID proposal
would feel predictable enough. Others disagreed.
- - - - - - - -
Well, the main reason why I prefer "AMBITIOUS" to "HYBRID" is that it
seems kind of peculiar to make an exception for the two functions,
SET-MACRO-CHARACTER and SET-DISPATCH-MACRO-CHARACTER. Besides being
different from all the other functions that take functional arguments,
it makes them different from the pathname functions (which always
coerce non-pathname "pathname" arguments to pathnames) and the package
functions (which always coerce non-package "package" arguments to
packages).
Also, I disagree that there is no performance penalty, although it's
certainly small in comparison to the rest of the reader's processing.
For example, A-Lisp has a fast, opencoded funcall primitive that it
uses when its argument is guaranteed to be a function, which is *much*
faster than a normal funcall (by a factor of at least 20).
I don't feel really strongly about this -- HYBRID is not really all
that objectionable to me, and I would vote for it if AMBITIOUS is
thrown out.
-------
... I'm thinking of a revision which might lean more toward
explicitly vague on some of these issues. At the same time,
I'd like to encourage the use of the DEBUG and/or SPEED quality
to help compilers lean toward LAZY in the slow/easy-to-debug
case and AMBITIOUS in the fast/hard-to-debug case. There are
some details to be worked out, though...
∂16-Mar-89 2244 X3J13-mailer Issue: SETF-FUNCTION-VS-MACRO, SETF-PLACES, FUNCTION-NAME, v.1
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 22:43:21 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 22:40:08 PST
Date: 16 Mar 89 22:34 PST
From: masinter.pa@Xerox.COM
Subject: Issue: SETF-FUNCTION-VS-MACRO, SETF-PLACES, FUNCTION-NAME, v.1
To: X3J13@sail.stanford.edu
line-fold: NO
Message-ID: <890316-224008-6866@Xerox>
This issue has been renamed several times; however, it is
the same old issue. I say this lest anyone think we can
'two week' it away.
We didn't have a 'letter ballot' and so we have to talk
about it. Maybe.
Additional Comments are at the end; including a fairly substantial
additional proposal.
!
Issue: FUNCTION-NAME
References: SETF rules for what -place- can be (pp.94-7)
FBOUNDP function (p.90)
FMAKUNBOUND function (p.92)
FUNCTION special form (p.87)
SYMBOL-FUNCTION and setf of symbol-function (p.90)
88-002R pages 1-21, 2-21, 2-26, 2-39, 2-44, 2-46, 2-51, and 2-55
(There are additional references for the MEDIUM and LARGE
proposals, but they are not listed here. They're obvious.)
Related issues: SETF-FUNCTION-VS-MACRO, SETF-PLACES (both subsumed by this)
Category: ADDITION
Edit history: Version 1, 23-Jan-89, by Moon
(based on discussion at X3J13 meeting)
Problem description:
The Common Lisp Object System needs a well-defined way to relate the name
and arguments of a writer function to those of a reader function, because
both functions can be generic and can have user-defined methods. The way
that was adopted into Common Lisp when X3J13 voted to accept document
88-002R was to use a list (SETF reader) as the name of the writer function.
Some changes to the non-object-oriented portion of Common Lisp are required
in order to support this.
This issue has three proposals.
Proposal (FUNCTION-NAME:SMALL):
Add a new concept "function-name" (called "function-specifier" in
88-002R). A function-name is either a symbol or a 2-element list whose
first element is the symbol SETF and whose second element is a symbol.
Implementations are free to extend the syntax of function-names to
include lists beginning with additional symbols other than SETF.
Add a new function (FDEFINITION function-name), which returns the
current global function definition named by function-name, or signals
an error if there is no global function definition. This follows all
the same rules listed for SYMBOL-FUNCTION in CLtL p.90.
Add SETF of FDEFINITION to change the current global function definition
named by a function-name. This follows all the same rules listed for
SETF of SYMBOL-FUNCTION in CLtL p.90.
Change the FBOUNDP and FMAKUNBOUND functions, and the FUNCTION special
form, to accept function-names in place of symbols. Implementation
defined extensions to the syntax of function-names cannot use the
symbol LAMBDA, since FUNCTION already uses that symbol.
Change the rules for SETF places (CLtL pp.94-7) by adding the following
clause after all the existing clauses:
- Any other list whose first element is a symbol, call it reader.
In this case, SETF expands into a call to the function named by the
list (SETF reader). The first argument is the new value and the
remaining arguments are the values of the remaining elements of
-place-. This expansion occurs regardless of whether reader or
(SETF reader) is defined as a function locally, globally, or not at
all. For example,
(SETF (reader arg1 arg2...) new-value)
expands into a form with the same effect and value as
(LET ((#:temp-1 arg1) ;force correct order of evaluation
(#:temp-2 arg2)
...
(#:temp-0 new-value))
(FUNCALL (FUNCTION (SETF reader)) #:temp-0 #:temp-1 #:temp-2...)).
Change the functions GET-SETF-METHOD and GET-SETF-METHOD-MULTIPLE-VALUE
to implement the above change to the rules.
Document that a function named (SETF reader) should return its first
argument as its only value, in order to preserve the semantics of SETF.
Change the macro DEFGENERIC and the function ENSURE-GENERIC-FUNCTION to
refer to the function FDEFINITION where they now refer to the function
SYMBOL-FUNCTION.
Change the macros DEFCLASS, DEFGENERIC, and DEFMETHOD, the special forms
GENERIC-FLET and GENERIC-LABELS, and the functions DOCUMENTATION and
ENSURE-GENERIC-FUNCTION to use the term "function-name" where they now
use the term "function-specifier" or "function specifier".
Rationale for FUNCTION-NAME:SMALL:
This is the minimum change to Common Lisp needed to do what 88-002R says
about (SETF reader). Giving implementations freedom to extend the syntax
of function-names allows for current practice. Changing the name from
"function-specifier" to "function-name" avoids confusion and improves
consistency with the rest of the language, at the cost of a few small
changes to 88-002R.
Proposal (FUNCTION-NAME:MEDIUM):
Everything in FUNCTION-NAME:SMALL, and in addition:
Change the DEFUN macro to accept a function-name for its name argument,
instead of only accepting a symbol. If function-name is (SETF sym),
the body is surrounded by an implicit block named sym.
Rationale for FUNCTION-NAME:MEDIUM:
Keeping DEFUN consistent with DEFMETHOD is a good idea. Also 88-002R
says "The name of a generic function, like the name of an ordinary
function, can be either a symbol or a two-element list whose...", which
implies this change to DEFUN.
Proposal (FUNCTION-NAME:LARGE):
Everything in FUNCTION-NAME:MEDIUM, and in addition the following
numbered points, each of which could be adopted independently,
except where explicitly noted:
1. Change the function COMPILE to accept a function-name as its name
argument.
2. Change the function DISASSEMBLE to accept a function-name as its name
argument.
3. Change the FTYPE, INLINE, and NOTINLINE declarations and proclamations
to accept function-names, not just symbols, as function names.
4. Change the FLET and LABELS special forms to accept a function-name in
the name position, not just a symbol.
5. Change the TRACE and UNTRACE macros to accept function-names, not just
symbols, in the function name positions.
6. Change the ED function to accept (ED function-name) in place of
(ED symbol).
7. Change the syntax of a function call to allow a function-name as the
first element of the list, rather than allowing only a symbol.
8. Change the DEFMACRO macro and the MACROLET special form to accept a
function-name in the name position, not just a symbol. Change the
MACRO-FUNCTION function to accept function-names, not just symbols.
Change the last rule for SETF places to use
((SETF reader) #:temp-0 #:temp-1 #:temp-2...)
in place of
(FUNCALL (FUNCTION (SETF reader)) #:temp-0 #:temp-1 #:temp-2...)
so that (SETF reader) can be defined as a macro. This depends on item
7. If item 4 is rejected, MACROLET should be stricken from this item.
9. Add an optional environment argument to FDEFINITION, SETF of
FDEFINITION, FBOUNDP, and FMAKUNBOUND. This is the same as the
&environment argument to a macroexpander. This argument can be used to
access local function definitions, to access function definitions in the
compile-time remote environment, and to modify function definitions in
the compile-time remote environment.
10. Change the second, third, fourth, fifth, seventh, and ninth rules for
SETF places so that they only apply when the function-name refers to the
global function definition, rather than a locally defined function or
macro. (The ninth rule is the one that refers to DEFSETF and
DEFINE-SETF-METHOD; the other rules listed are the ones that list
specific built-in functions). The effect of this change is that SETF
methods defined for global functions are ignored when there is a local
function binding; instead, the function named (SETF reader), which may
have a local function binding, is called. This change is most useful
in connection with item 4, but does not actually depend on it.
11. Clarify that the eighth rule for SETF places (the one for macros)
uses MACROEXPAND-1, not MACROEXPAND.
Rationale for FUNCTION-NAME:LARGE:
This extends the new feature throughout the language, in order to make
things generally more consistent and powerful. Point by point:
1,2,3 - one should be able to compile, examine, and make declarations
about functions regardless of whether they are named with symbols or
with lists.
4 - locally defined non-generic SETF functions are a logical companion
to locally defined generic SETF functions, which can be defined with
GENERIC-FLET or GENERIC-LABELS. They make sense on their own, since one
might define a local reader function and want a local writer function
to go with it.
5,6 - one should be able to apply development tools to functions
regardless of how they are named. The function DOCUMENTATION was already
updated to work for function-names by 88-002R. There might be some
difficulty with implementation-dependent syntax extensions to TRACE and
UNTRACE conflicting with this new syntax.
7 - this restores consistency between the FUNCTION special form and the
first element of a function call form.
8 - it seems more consistent to allow macros to be named the same way
that ordinary functions are named. However, this might be considered
redundant with DEFSETF.
9 - this is not needed by the "chapter 1 and 2" level of CLOS, but might
be used by the metaobject based implementation of ENSURE-GENERIC-FUNCTION.
10 - this change was in SETF-FUNCTION-VS-MACRO and makes item 4 more useful.
11 - this change was in SETF-FUNCTION-VS-MACRO and is a good idea, but
actually is independent of everything else being proposed here.
Examples:
;This is an example of the sort of syntax 88-002R allows
(defmethod (setf child) (new-value (parent some-class))
(setf (slot-value 'child parent) new-value)
(update-dependencies parent)
new-value)
(setf (child foo) bar)
;If SETF of SUBSEQ was not already built into Common Lisp,
;it could have been defined like this, if the MEDIUM or LARGE
;proposal is adopted.
(defun (setf subseq) (new-value sequence start &optional end)
(unless end (setq end (length sequence)))
(setq end (min end (+ start (length new-value))))
(do ((i start (1+ i))
(j 0 (1+ j)))
((= i end) new-value)
(setf (elt sequence i) (elt new-value j))))
;The preceding example would have to be defined like this
;if only the SMALL proposal is adopted. This is a method
;all of whose parameter specializer names are T.
(defmethod (setf subseq) (new-value sequence start &optional end)
(unless end (setq end (length sequence)))
(setq end (min end (+ start (length new-value))))
(do ((i start (1+ i))
(j 0 (1+ j)))
((= i end) new-value)
(setf (elt sequence i) (elt new-value j))))
;Another example, showing a locally defined setf function
(defun frobulate (mumble)
(let ((table (mumble-table mumble)))
(flet ((foo (x)
(gethash x table))
((setf foo) (new x)
(setf (gethash x table) new)))
..
(foo a)
..
(setf (foo a) b))))
;get-setf-method could implement setf functions by calling
;this function when the earlier rules do not apply
(defun get-setf-method-for-setf-function (form)
(let ((new-value (gensym))
(temp-vars (do ((a (cdr form) (cdr a))
(v nil (cons (gensym) v)))
((null a) v))))
(values temp-vars
(cdr form)
(list new-value)
`(funcall #'(setf ,(car form)) ,new-value ,@temp-vars)
`(,(car form) ,@temp-vars))))
Current practice:
No implementation supports exactly what is proposed. Symbolics Genera
and the TI Explorer support something close to the MEDIUM proposal, but
differing in a number of details. Symbolics Genera supports items 1, 2,
3, 6, and 11, and modified forms of items 5 and 8, of the LARGE proposal.
Moon considers this proposal's variations from Symbolics current practice
to be an improvement, although incompatible in some cases.
Many implementations currently support only symbols as function names.
Symbolics Genera and the TI Explorer have some additional function-name
syntaxes.
Cost to Implementors:
The SMALL and MEDIUM proposals are estimated to be no more than 50 lines
of code and require no changes to the "guts" of the interpreter and
compiler. Most of the code for this can be written portably and was
shown on two slides at the X3J13 meeting.
Some of the changes in the LARGE proposal are trivial, some require
the compiler to use EQUAL instead of EQ to compare function names, and
items 4, 7, and 8 might require a more substantial implementation
effort. Even that effort is estimated to be negligible compared to
the effort required to implement CLOS.
Cost to Users:
No cost to users, other than program-understanding programs, since this
is an upward compatible addition.
As with any language extension, some program-understanding programs may
need to be enhanced. A particular issue here is programs that assume
that all function names are symbols. They may use GET to access
properties of a function name or use EQ or EQL (perhaps via MEMBER or
ASSOC) to compare function names for equality. Such programs will need
improvement before they can understand programs that use the new feature,
but otherwise they will still work.
Cost of non-adoption:
We would have to make some other language change since the language
became inconsistent when 88-002R was adopted.
Performance impact:
This has no effect on performance of compiled code. It might slow
down the compiler and interpreter but not by very much.
Benefits:
CLOS will work as designed.
Esthetics:
Some people dislike using anything but symbols to name functions.
Other people would prefer that if the change is to be made at all,
the LARGE proposal be adopted so that the language is uniform in its
treatment of the new extended function names. Other proposals for
how to deal with SETF in CLOS were considerably less esthetic,
especially when package problems are taken into account.
SETF would be more esthetic, but less powerful, if it had only the
proposed setf functions and did not have setf macros. Such a major
incompatible change is of course out of the question; however, if setf
functions are stressed over setf macros, SETF will be much easier to
teach.
Discussion:
Moon supports at least FUNCTION-NAME:MEDIUM. He does not necessarily
approve of all parts of FUNCTION-NAME:LARGE.
!
Additional Comments:
On the whole, I like this presentation much better than either of the
other two writeups that were circulated previously. I suspect that it
might be necessary to vote on each of the items in the LARGE proposal
individually, though. I think I would support items 1, 2, and 11, and
don't have any particular objections to 3, 5, and 6. For item 4, if
consistency with GENERIC-FLET and GENERIC-LABELS is an object, another
alternative is to change those two special forms to be like ordinary
FLET and LABELS, instead of vice versa.
- - - - - - -
I support FUNCTION-NAME:MEDIUM and may support LARGE once I think about
it some more.
As I explained in Hawaii, support for either of these is based on the
:conc-name bugs being removed from the condition system. Of course, I
believe the best way to do that is to CLOSify it.
- - - - - - - -
I'm still thinking about this, but while I am I wanted point out that
MEDIUM is unacceptable to me because I don't think FLET and DEFUN should
disagree on what they permit as defined names. If FLET were added to
MEDIUM, I suspect I'd think it was an internally consistent position.
LARGE has an appeal to me in general, but I'm still mulling over
the specifics.
- - - - - - - - - -
I favor the FUNCTION-NAME:LARGE proposal, because it defines a single,
useful notion of what a function name is. The other proposals have
the flaw that there are two kinds of function names: symbols, and
extended names, with only some of the Lisp primitives accepting the
latter. This may be convenient for some implementations, for the
short term, but it fragments the language.
I have two other comments on the proposal.
A. Reducing the Cost to Implementors
One observation you could put in the Cost To Implementors section is
that none of the SMALL, MEDIUM, or LARGE proposals require changes to
the "guts" of the interpreter and compiler. This is because an
implementation is free to use plain symbols internally to name
functions, and use a hack like JonL's SETF:|3.FOO.BAR| mapping to
convert non-symbol names to symbols. This conversion would be done as a
part of parsing the handful of forms which accept function names, and
then all other passes of the interpreter and compiler (the "guts") would
just see symbols. (By "parsing" I mean ensuring the right number and
type of syntactic subforms. You can see that this is a very early and
simple stage of processing.) Or, Lisp compilers with an "alphatization"
phase could perform function name symbolization at that phase.
B. Finishing the Job of Regularization
I'd like to suggest two additions to your smorgasbord of options in the
FUNCTION-NAME:LARGE section of the proposal. One addition would
regularize a major special case of functions--lambda expressions. The
other addition would reaffirm an unstated regularity in the language,
that function names can stand in for functions under FUNCALL and APPLY.
Not only can the treatment of symbolic and setf-list function names be
regularized, but lambda too can be treated in a consistent manner.
If these two points are added to your proposal, the language as a whole
would have a completely uniform treatment of functions and function
names. Here they are:
13. Declare that any function name is a suitable argument to FUNCALL and
APPLY. In such a case, the function name is passed to FDEFINITION,
and the result (which may in turn be a function name) is called.
That is, the following two expressions are equivalent, when fname
is a function name:
(FUNCALL fname x y)
<==>
(FUNCALL (FDEFINITION fname) x y)
Note that the definition is sought in the global environment.
Compare with the rule which applies to a function name occurs,
syntactically, as the car of a list in code:
(fname x y)
<==>
(FUNCALL (FUNCTION fname) x y)
<==> (under proposal item 9)
(FUNCALL (FDEFINITION fname <local-environment>) x y)
12. Declare that any lamba expression (i.e., a list whose car is LAMBDA and
whose cdr is a well-formed lambda argument list and body) is a function
name. The effects of the function name accessors on lambda expressions
are as follows. FDEFINITION returns an implementation-defined value which
is the function specified the lambda expression, closed in the global
environment. This FDEFINITION value cannot be changed by SETF.
FBOUNDP always returns T, and MAKUNBOUND is an error.
Esthetics:
The effect of items 11 and 12 is to complete the regularization of
Common Lisp's treatment of functions and function names. The total
effect of proposal items 1 through 12 is that Lisp has just two notions
for referencing function objects: FUNCTIONS, which are Lisp objects that
directly represent executable code, and FUNCTION NAMES, which can denote
functions. Symbols, SETF function names, and lambda expressions are all
examples of the latter notion. The former notion is highly
implementation dependent. Function names can occur as syntactic
entities in code. FUNCALL and APPLY work uniformly on both functions
and function names, with a consistent semantics.
Lambda expressions are often thought to denote "anonymous" functions, so
it may seem paradoxical to treat them as names. The paradox is only
apparent, since the expression itself has the properties of a Lisp
function name: It is (typically) a cons tree which can be read, printed,
and stored in source files, and it denotes a well-defined Lisp function.
Benefit to Users:
Function names are useful for representing objects in remote
environments, because they need not be bound at all times to the same
function, or to any function, and because they are typically stable in
meaning across reads and prints, where plain functions are not.
Programs which deal simultaneously with remote and local environments,
such as CLOS, can probably be simplified, since function names
can be used uniformly, rather than an ad-hoc mixture of functions
and function names.
The language as a whole become more uniform from these additions and
clarifications, making it easier to learn and use. (See Esthetics.)
Cost to Implementors:
Interpreters which currently have a special case check for application
of lambda expressions would need to modify this check to call
FDEFINITION when a list of any sort is encountered. Note that all
Common Lisps already must perform some such check, since lambda
expressions can be funcalled (and this is currently a very special case,
the only standard case of a list being funcalled). This means that
every Lisp already has a place to insert the required call to
FDEFINITION.
In some implementations, FDEFINITION of a lambda expression could be that
lambda-expression itself. In others featuring a pre-eval codewalk, the
walk would be done by FDEFINITION, which would return an appropriate
closure.
Cost of Non-adoption:
Rather than two notions for function references (functions and function
names), there would be several notions, each corresponding to the valid
inputs for particular group of primitives. APPLY and FUNCALL would
accept functions, symbolic names, and lambda expressions, but not setf
function names. FDEFINITION and its kind would accept symbols and setf
function names but not lambda expressions. If the :LARGE proposal is
not adopted, this fragmentation would also apply to the various syntaxes
involving function names; some names would be acceptable to DEFUN
but not to FLET, etc.
- - - - - - - - - - - - -
> 13. Declare that any function name is a suitable argument to FUNCALL and
> APPLY. In such a case, the function name is passed to FDEFINITION,
> and the result (which may in turn be a function name) is called.
I don't think this is such a good idea. The case of automatically coercing
a symbol to a function is needed because it provides a portable mechanism
for indirect addressing of a function; I haven't seen a reason to need this
for non-symbol function specs. But more important is that coercing a
symbol to a function is a trivial operation that is reasonable to do at
run time on each call without adding a significant amount of overhead.
FDEFINITION, on the other hand, is a much more expensive operation -- at
best it might use GET to do a property list lookup, or it could be using
string-append and INTERN to convert the name to a symbol. In either case,
I think this is more work than you want to do on each call.
> 12. Declare that any lamba expression (i.e., a list whose car is LAMBDA and
> whose cdr is a well-formed lambda argument list and body) is a function
> name. The effects of the function name accessors on lambda expressions
> are as follows. FDEFINITION returns an implementation-defined value which
> is the function specified the lambda expression, closed in the global
> environment. This FDEFINITION value cannot be changed by SETF.
> FBOUNDP always returns T, and MAKUNBOUND is an error.
The exceptions for SETF and MAKUNBOUND show that this is not really as
consistent as you might like. Furthermore, the FUNCTION special form would
have to treat a LAMBDA expression as a function, not a function name, in
order for it to be lexically scoped. It seems like this might just cause
confusion rather than consistency.
∂16-Mar-89 2254 X3J13-mailer Issue: HASH-TABLE-ACCESS (version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 22:53:48 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 22:51:36 PST
Date: 16 Mar 89 22:51 PST
From: masinter.pa@Xerox.COM
Subject: Issue: HASH-TABLE-ACCESS (version 2)
to: X3J13@sail.stanford.edu
Line-fold: NO
Message-ID: <890316-225136-6875@Xerox>
Version 1 of this issue was distributed prior
to the October 1988 meeting.
This version was produced in response to
comments there.
Additional comments are at the end.
!
Issue: HASH-TABLE-ACCESS
References: hash-tables (Chapter 21 of CLtL)
Category: ADDITION
Edit History: 13-Sept-88, version 1 by Walter van Roggen
13-Oct-88, version 2 by Walter van Roggen
Problem Description:
There are many characteristics of hash-tables which are specified upon
creation but are not accessible afterwards.
Proposal: (HASH-TABLE-ACCESS:PROVIDE)
Add the following functions to the language:
HASH-TABLE-REHASH-SIZE hash-table
Returns the current rehash size of a hash table.
HASH-TABLE-REHASH-THRESHOLD hash-table
Returns the current rehash threshold of a hash table.
HASH-TABLE-SIZE hash-table
Returns the current size of a hash table.
HASH-TABLE-TEST hash-table
Returns the test used for comparing keys in the hash table.
By default the value will be EQL.
Current Practice:
VAX LISP and Lucid 3.0 implement the proposal.
Cost to Implementors:
Most of these should be trivial to implement, since the information
must be present for nearly all types.
Cost to Users:
None. This is an upward-compatible extension.
Cost of Non-Adoption:
The benefits would not be available in a portable fashion.
Benefits:
Programs would be able to access useful information otherwise hidden.
For example, it would allow programs to gain statistics about hash
table usage that might enable better tuning.
Discussion:
None of these are required to be SETF'able, though some might be
reasonable implementation-dependent extensions. Including such
modification abilities might constrain some implementations unduly.
This first appeared in ">GLS>clarifications.text" of 12/06/85.
!
Additional Comments:
Adding accessors for hash tables seems like a reasonable idea to me,
but I don't like the idea of being able to SETF them.
- - - - -
HASH-TABLE-REHASH-SIZE hash-table
Returns the current rehash size of a hash table.
HASH-TABLE-REHASH-THRESHOLD hash-table
Returns the current rehash threshold of a hash table.
HASH-TABLE-SIZE hash-table
Returns the current size of a hash table.
I don't think the "current" values of these are well defined except in
reference to one particular implementation technique (I believe the
corresponding arguments to make-hash-table are advisory in nature and can be
ignored when not applicable). For instance, can you describe what an
implementation using alists should return from each of these functions?
I do support the addition of HASH-TABLE-TEST.
- - - - - - -
Well, I think there would be some leeway on the return values for
HASH-TABLE-REHASH-SIZE/REHASH-THRESHOLD/SIZE too.
If an implementation really did implement them with association lists,
perhaps reasonable return values would be:
HASH-TABLE-REHASH-SIZE 1
HASH-TABLE-REHASH-THRESHOLD 1.0
HASH-TABLE-SIZE the length of the association list
- - - - - - -
I still would like to see SETF enabled for:
HASH-TABLE-REHASH-SIZE
HASH-TABLE-REHASH-THRESHOLD
At issue is the rate of "rehashing" between successive, novel entries
into the table, and the rate of consing to maintain the table. [Perhaps
this would be clearer if there were a function in the language called
REHASH; Lucid 3.0 has such a function, and Interlisp-D had such a function.]
Of course, the setf methods for these two accessors would do a good deal of
argument and consistency checking. So what possible harm could come from
permitting the user to alter these parameters after initial creation? those
implementations that substitute alists for "hash-tables" can try to adapt to
this view, that some kind of "rehash" step [with some determined cost] is
done after the entry which first makes:
(hash-table-count x) > (* (hash-table-size x)
(hash-table-rehash-threshold x))
be true [assuming a floating-point value for the threshold]. This is part
of the whole point for having "hash tables" in the language.
- - - - -
I'm quite sympathetic to being able to SETF some of the hash-table readers,
but I didn't think it appropriate to require of all implementations.
- - - - - -
The value of HASH-TAbLE-REHASH-SIZE and HASH-TAbLE-REHASH-THRESHOLD are
implementation dependent, and guaranteed to be greater than or equal to the
values given to MAKE-HASH-TABLE, and idempotent, in that if you make a hash
table with the same values as a given hash table then the -REHASH-SIZE and
-REHASH-THRESHOLD of the newly created one will be the same as the input
values. (This says that they may be thresholded upward in some
implementation-dependent-manner.)
HASH-TABLE-SIZE should be greater than or equal to the count of things
MAPHASH would iterate over, and HASH-TABLE-TEST will return one of the
symbols EQ EQL EQUAL (or, if HASH-TABLE-TESTS passes, EQUALP), even if #'EQ
#'EQUAL #'EQL are given.
Normally implementation-dependent-extensions are explicitly discouraged;
I'm no longer sure at the momemnt whether PACKAGE-CLUTTER would explicilty
disallow such extensions unless they are explicitly allowed, but we should
be cautious in throwing around phrases like "might be
reasonable implementation-dependent extensions" if we don't mean it. I
would take that out, actually.
∂16-Mar-89 2330 X3J13-mailer Issue: LOAD-OBJECTS (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 23:30:04 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 23:27:37 PST
Date: 16 Mar 89 23:26 PST
From: masinter.pa@Xerox.COM
Subject: Issue: LOAD-OBJECTS (Version 3)
To: x3j13@sail.stanford.edu
line-fold: NO
Message-ID: <890316-232737-6946@Xerox>
Version 1 was distributed in hardcopy form and discussed
at the January 1989 meeting.
Discussion so far has been considering alternatives of
load functions rather than load forms, or having two
generic functions.
!
Issue: LOAD-OBJECTS
References: none
Related issues: LOAD-TIME-EVAL,
CONSTANT-COMPILABLE-TYPES,
CONSTANT-CIRCULAR-COMPILATION
Category: ADDITION
Forum: Cleanup
Edit history: Version 1, 2-Jan-89, by Moon (for discussion)
Version 2, 13-Jan-89, by Moon (draft updated from discussion)
Version 3, 9-Mar-89, by Moon (changes suggested by discussion)
Problem description:
Common Lisp doesn't provide any way to use an object of a user-defined
type (defined with DEFCLASS or DEFSTRUCT) as a constant in a program
compiled with COMPILE-FILE. The problem is that LOAD has to be able
to "reconstruct" an equivalent object when the compiled-code file is
loaded, but the programmer has no way to tell LOAD how to do that.
Proposal (LOAD-OBJECTS:MAKE-LOAD-FORM):
Define a new generic function named MAKE-LOAD-FORM, which takes one
argument and returns two values. The argument is an object that is
referenced as a constant or as a self-evaluating form in a file being
compiled by COMPILE-FILE. The objective is to enable LOAD to
construct an equivalent object.
The first value, called the "creation form," is a form that, when
evaluated at load time, should return an object that is equivalent to
the argument. The exact meaning of "equivalent" depends on the type
of object and is up to the programmer who defines a method for
MAKE-LOAD-FORM. This is the same type of equivalence discussed
in issue CONSTANT-COMPILABLE-TYPES.
The second value, called the "initialization form," is a form that,
when evaluated at load time, should perform further initialization of
the object. The value returned by the initialization form is ignored.
If the MAKE-LOAD-FORM method returns only one value, the
initialization form is NIL, which has no effect. If the object used
as the argument to MAKE-LOAD-FORM appears as a constant in the
initialization form, at load time it will be replaced by the
equivalent object constructed by the creation form; this is how the
further initialization gains access to the object.
Both the creation form and the initialization form can contain
references to objects of user-defined types (defined precisely below).
However, there must not be any circular dependencies in creation forms.
An example of a circular dependency is when the creation form for the
object X contains a reference to the object Y, and the creation form
for the object Y contains a reference to the object X. A simpler
example would be when the creation form for the object X contains
a reference to X itself. Initialization forms are not subject to
any restriction against circular dependencies, which is the entire
reason that initialization forms exist. See the example of circular
data structures below.
The creation form for an object is always evaluated before the
initialization form for that object. When either the creation form or
the initialization form references other objects of user-defined types
that have not been referenced earlier in the COMPILE-FILE, the
compiler collects all of the creation and initialization forms. Each
initialization form is evaluated as soon as possible after its
creation form, as determined by data flow. If the initialization form
for an object does not reference any other objects of user-defined
types that have not been referenced earlier in the COMPILE-FILE, the
initialization form is evaluated immediately after the creation form.
If a creation or initialization form F references other objects of
user-defined types that have not been referenced earlier in the
COMPILE-FILE, the creation forms for those other objects are evaluated
before F, and the initialization forms for those other objects are
also evaluated before F whenever they do not depend on the object
created or initialized by F. Where the above rules do not uniquely
determine an order of evaluation, which of the possible orders of
evaluation is chosen is unspecified.
While these creation and initialization forms are being evaluated, the
objects are possibly in an uninitialized state, analogous to the state
of an object between the time it has been created by ALLOCATE-INSTANCE
and it has been processed fully by INITIALIZE-INSTANCE. Programmers
writing methods for MAKE-LOAD-FORM must take care in manipulating
objects not to depend on slots that have not yet been initialized.
It is unspecified whether LOAD calls EVAL on the forms or does some
other operation that has an equivalent effect. For example, the
forms might be translated into different but equivalent forms and
then evaluated, they might be compiled and the resulting functions
called by LOAD, or they might be interpreted by a special-purpose
interpreter different from EVAL. All that is required is that the
effect be equivalent to evaluating the forms.
COMPILE-FILE calls MAKE-LOAD-FORM on any object that is referenced as
a constant or as a self-evaluating form, if the object's metaclass is
STANDARD-CLASS, STRUCTURE-CLASS, any user-defined metaclass (not a
subclass of BUILT-IN-CLASS), or any of a possibly-empty
implementation-defined list of other metaclasses. COMPILE-FILE will
only call MAKE-LOAD-FORM once for any given object (compared with EQ)
within a single file.
It is valid for user programs to call MAKE-LOAD-FORM in other
circumstances, providing the argument's metaclass is not BUILT-IN-CLASS
or a subclass of BUILT-IN-CLASS.
Define a new function named MAKE-LOAD-FORM-USING-SLOTS, which takes
one required argument and one optional argument and returns two
values. This can be useful in user-written MAKE-LOAD-FORM methods.
The first argument is the object. The optional second argument is a
list of the names of the slots to preserve; it defaults to all of the
local slots. MAKE-LOAD-FORM-USING-SLOTS returns forms that construct
an equivalent object using MAKE-INSTANCE and SETF of SLOT-VALUE for
slots with values, or SLOT-MAKUNBOUND for slots without values, or
using other functions of equivalent effect.
MAKE-LOAD-FORM-USING-SLOTS returns two values, thus it can deal with
circular structures. MAKE-LOAD-FORM-USING-SLOTS works for any object
of metaclass STANDARD-CLASS or STRUCTURE-CLASS. Whether the result is
useful in an application depends on whether the object's type and slot
contents fully capture the application's idea of the object's state.
MAKE-LOAD-FORM of an object of metaclass STANDARD-CLASS or
STRUCTURE-CLASS for which no user-defined method is applicable signals
an error. It is valid to implement this either by defining default
methods on STANDARD-OBJECT and STRUCTURE-OBJECT that signal an error
or by having no applicable method for those classes.
Examples:
;; Example 1
(defclass my-class ()
((a :initarg :a :reader my-a)
(b :initarg :b :reader my-b)
(c :accessor my-c)))
(defmethod shared-initialize ((self my-class) ignore &rest ignore)
(unless (slot-boundp self 'c)
(setf (my-c self) (some-computation (my-a self) (my-b self)))))
(defmethod make-load-form ((self my-class))
`(make-instance ',(class-name (class-of self))
:a ',(my-a self) :b ',(my-b self)))
In this example, an equivalent instance of my-class is reconstructed
by using the values of two of its slots. The value of the third slot
is derived from those two values.
Another way to write the last form in the above example would have been
(defmethod make-load-form ((self my-class))
(make-load-form-using-slots self '(a b)))
;; Example 2
(defclass my-frob ()
((name :initarg :name :reader my-name)))
(defmethod make-load-form ((self my-frob))
`(find-my-frob ',(my-name self) :if-does-not-exist :create))
In this example, instances of my-frob are "interned" in some way.
An equivalent instance is reconstructed by using the value of the
name slot as a key for searching existing objects. In this case
the programmer has chosen to create a new object if no existing
object is found; alternatively she could have chosen to signal an
error in that case.
;; Example 3
(defclass tree-with-parent () ((parent :accessor tree-parent)
(children :initarg :children)))
(defmethod make-load-form ((x tree-with-parent))
(values
;; creation form
`(make-instance ',(class-of x) :children ',(slot-value x 'children))
;; initialization form
`(setf (tree-parent ',x) ',(slot-value x 'parent))))
In this example, the data structure to be dumped is circular, because
each parent has a list of its children and each child has a reference
back to its parent. Suppose make-load-form is called on one object in
such a structure. The creation form creates an equivalent object and
fills in the children slot, which forces creation of equivalent
objects for all of its children, grandchildren, etc. At this point
none of the parent slots have been filled in. The initialization form
fills in the parent slot, which forces creation of an equivalent
object for the parent if it was not already created. Thus the entire
tree is recreated at load time. At compile time, MAKE-LOAD-FORM is
called once for each object in the true. All of the creation forms
are evaluated, in unspecified order, and then all of the
initialization forms are evaluated, also in unspecified order.
;; Example 4
(defstruct my-struct a b c)
(defmethod make-load-form ((s my-struct))
(make-load-form-using-slots s))
In this example, the data structure to be dumped has no special
properties and an equivalent structure can be reconstructed
simply by reconstructing the slots' contents.
Rationale:
Only the programmer who designed a class can know the correct
way to reconstruct objects of that class at load time, therefore
the reconstruction should be controlled by a generic function.
Using EVAL as the interface for telling LOAD what to do provides
full generality.
MAKE-LOAD-FORM returns two values so that circular structures can
be handled. If CONSTANT-CIRCULAR-COMPILATION is rejected,
MAKE-LOAD-FORM will only return one value, although implementations
that make an extension to support circular constants will probably
also make the extension to accept two values from MAKE-LOAD-FORM.
The default for class objects and structures is to signal an error,
rather than picking some particular object reconstruction technique,
because no reconstruction technique is appropriate for all objects.
It only takes two lines of code, as in example 4, to instruct the
compiler to use the technique that most often has been suggested
as the default.
MAKE-LOAD-FORM has a natural resemblance to PRINT-OBJECT, as a hook
for the programmer to control the system's actions.
The order of evaluation rules for creation and initialization forms
eliminate the possibility of partially initialized objects in the
absence of circular structures, and reduce it to the minimum possible
in the presence of circular structures. This allows nodes in
non-circular structures to be built out of fully initialized subparts.
Current practice:
Symbolics Flavors has something like this, but under a different name.
The name Symbolics uses is not suitable for standardization.
JonL reports that Lucid is getting more and more requests for this.
Cost to Implementors:
This seems like only a few one-line changes in the compiled-code
file writer and reader. MAKE-LOAD-FORM-USING-SLOTS is a couple
dozen lines of code, assuming the presence of the CLOS metaobject
protocol or an implementation-dependent equivalent.
Cost to Users:
None.
Cost of non-adoption:
Serious impairment of the ability to use extended-type objects. Each
implementation will probably make up its own version of this as an
extension.
Performance impact:
None.
Benefits:
See Cost of non-adoption.
Esthetics:
No significant positive or negative impact.
Discussion:
It would be possible to define an additional level of protocol that
allows multiple classes to contribute to the reconstruction of an
object, combining initialization arguments contributed by each class.
Since a user can easily define that in terms of MAKE-LOAD-FORM without
modifying the Lisp system, it is not being proposed now.
Any type that has a read syntax is likely to appear as a quoted
constant or inside a quoted constant. Pathnames are one example, user
programs often define others. Also many implementations provide a way
to create a compiled-code file full of data (rather than compiled Lisp
programs), and such data probably include extended-type objects.
Moon supports this. David Gray and John Rose made major contributions
to the discussion that produced this improved version 2 proposal.
----- End Forwarded Messages -----
∂16-Mar-89 2334 X3J13-mailer Issue LOOP-AND-DISCREPANCY, version 1
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 23:34:11 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 23:32:03 PST
Date: 16 Mar 89 23:31 PST
From: masinter.pa@Xerox.COM
To: X3J13@sail.stanford.edu
Subject: Issue LOOP-AND-DISCREPANCY, version 1
line-fold: NO
Message-ID: <890316-233203-6953@Xerox>
!
Issue: LOOP-AND-DISCREPANCY
References: Loop Facility document X3J13/89-004
Related issues:
Category: CHANGE CLARIFICATION
Edit history: Version 1, 15-Mar-88 by Steele
Problem description:
The treatment of the AND conjunction in FOR/AS and WITH clauses is not
consistent. Examples of the use of WITH are also not consistent in this
respect.
Page 2-5 implies by example that when AND is used to join two
FOR/AS clauses, the word FOR or AS must occur after the word AND.
Page 2-31 has formal syntax specifying that when AND is used to join two
WITH clauses, the word WITH must *not* occur after the word AND. Examples
on that page are consistent with this specification.
Page 2-41 has an example in which WITH is repeated after AND.
Proposal (LOOP-AND-DISCREPANCY:NO-REITERATION):
Let stand the formal syntax for WITH.
Change the description of FOR/AS clauses to specify that when
two or more such clauses are joined with AND, clauses after the
first do not have FOR or AS before them.
The complete formal syntax for FOR/AS may be described as follows:
for-as ::= {FOR | AS} for-as-subclause {AND for-as-subclause}*
for-as-subclause ::= for-as-arithmetic | for-as-in-list
| for-as-on-list | for-as-equals-then
| for-as-across | for-as-hash | for-as-package
for-as-arithmetic ::= var [type-spec] ...
and so on.
Examples:
> (loop for x from 1 to 10 ;Corrected from X3J13/89-004, page 2-5
and y = nil then x
collect (list x y))
((1 NIL) (2 1) (3 2) (4 3) (5 4) (6 5) (7 6) (8 7) (9 8) (10 9))
> (loop with (a b) float = '(1.0 2.0) ;Corrected from X3J13/89-004, page 2-41
and (c d) integer = '(3 4)
and (e f)
return (list a b c d e f))
(1.0 2.0 3 4 nil nil)
Rationale:
The treatment of AND should be internally consistent. There is no reason
to repeat the FOR/AS keyword. Not repeating the keyword emphasizes that
the subclauses are functionally linked under the heading of WITH or FOR.
(Compare to the third use of AND in LOOP, to link clauses controlled
by WHEN/IF/UNLESS. One does not repeat the WHEN; rather, the clauses
grouped by AND are controlled by a single WHEN.)
Current practice:
Symbolics LOOP allows FOR to be included or omitted after AND,
with identical meanings. WITH may not be repeated after AND.
Cost to Implementors: Small?
Cost to Users: Possible incompatibility with existing implementors' extensions.
Cost of non-adoption: Utter confusion.
Performance impact: None.
Benefits: Consistent treatment of AND within LOOP.
Esthetics:
Absolutely none. We're talking about LOOP here.
Discussion:
Steele supports this proposal. It is a reversal of his previous
suggestion on the topic, thanks to feedback from Moon.
----- End Forwarded Messages -----
∂17-Mar-89 0009 X3J13-mailer Issue: REAL-NUMBER-TYPE (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 00:08:54 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 23:50:31 PST
Date: 16 Mar 89 23:49 PST
From: masinter.pa@Xerox.COM
Subject: Issue: REAL-NUMBER-TYPE (version 3)
To: x3J13@Sail.Stanford.EDU
Message-ID: <890316-235031-6996@Xerox>
!
Issue: REAL-NUMBER-TYPE
Forum: CLEANUP
References: Table 4-1.
Category: ADDITION
Edit history: 04-JAN-89, Version 1 by Bob Cassels, Don Sakahara, Kent Pitman,
and John Aspinall
08-JAN-89, Version 2 by Bob Cassels -- incorporate
Masinter's suggestion and make REAL a CLOS class
13-JAN-89, Version 3 by Cassels and Aspinall -- incorporate Marc LeBrun's
suggestions clarifying the relationship between CL
numeric type names and mathematical names
Status: For Internal Discussion
Problem Description:
There is no standard type specifier symbol for the CL type
'(OR RATIONAL FLOAT).
Proposal (REAL-NUMBER-TYPE:REAL):
Make REAL be a CL data type:
p.13 "Numbers"
Add: The NUMBER data type encompasses all of these kinds of
numbers. For convenience, there are names for some
subclasses of numbers. @i[Integers] and @i[ratios] are of
type RATIONAL. @i[Rational numbers] and @[floating-point
numbers] are of type REAL. @i[Real numbers] and @i[complex
numbers] are of type NUMBER.
Although the names of these types were chosen with the
terminology of mathematics in mind, the correspondences
are not always exact. Integers and ratios model the
corresponding mathematical concepts directly. Numbers
of the FLOAT type may be used to approximate real
numbers, both rational and irrational. The REAL type
includes all Common Lisp numbers which represent
mathematical real numbers, though there are
mathematical real numbers (irrational numbers)
which do not have an exact Common Lisp representation.
Only REAL numbers may be ordered using the <, >, <=,
and >= functions.
Compatibility note: The Fortran standard defines the term
"real datum" to mean "a processor approximation to the value
of a real number." In practice the Fortran "basic real" type
is the floating-point data type Common Lisp calls
SINGLE-FLOAT. The Fortran "double precision" type is
Common Lisp's DOUBLE-FLOAT. The Pascal "real" data type is
an "implementation-defined subset of the real numbers." In
practice this is usually a floating-point type, often what
Common Lisp calls DOUBLE-FLOAT.
A translation of an algorithm written in Fortran or Pascal
which uses "real" data usually will use some appropriate
precision of Common Lisp's FLOAT type. Some algorithms may
gain accuracy and/or flexibility by using Common Lisp's
RATIONAL or REAL types instead.
p.33 "Overlap, Inclusion, and Disjointness of Types":
Remove: The types RATIONAL, FLOAT, and COMPLEX are pairwise
disjoint subtypes of NUMBER.
Rationale: It might be thought that INTEGER and RATIO ...
Rationale: It might be thought that FIXNUM and BIGNUM ...
Add: The types RATIONAL and FLOAT are pairwise disjoint subtypes
of REAL.
The types REAL and COMPLEX are pairwise disjoint subtypes
of NUMBER.
Rationale: It might be thought that FIXNUM and BIGNUM should
form an exhaustive partition of the type INTEGER, that INTEGER
and RATIO should form an exhaustive partition of RATIONAL,
that RATIONAL and FLOAT should form an exhaustive partition of
REAL, and that REAL and COMPLEX should form an exhaustive
partition of NUMBER. These are all purposely avoided in order
to permit compatible experimentation with extensions to the
Common Lisp number system, such as the idea of adding explicit
representations of infinity or of positive and negative infinity.
p.43 Table 4-1 "Standard Type Specifier Symbols"
Add: REAL
p.49 "Type Specifiers that Abbreviate"
Add: (REAL low high)
Denotes the set of real numbers between low and high. ...
[As with RATIONAL and FLOAT.]
Make REAL a built-in CLOS class.
Proposal (REAL-NUMBER-TYPE:REALP):
Add a specific data type predicate REALP which tests for membership in
this type. [By analogy with NUMBERP.]
Test Case:
If a programmer wishes to test for "a number between 1 and 10", the
only current CL types would be '(or (rational 1 10) (float 1 10)) or
something like '(and numberp (not complexp) (satisfies range-1-10))
with (defun range-1-10 (real) (<= 1 real 10)). Both of these are
likely less efficient, and certainly less expressive than '(real 1 10).
Rationale:
Mathematics has a name for (OR RATIONAL FLOAT) -- it is "real".
This class is important because it is all the numbers which can be
ordered.
Throughout the "Numbers" chapter, the phrase "non-complex number" is
used.
MAX, MIN, p. 198 "The arguments may be any non-complex numbers."
CIS p. 207 "The argument ... may be any non-complex number."
Current Practice:
Probably nobody does this.
Cost to Implementors:
Some work is necessary to add this name. But since the underlying
type already exists the amount of work should be minimal.
Cost to Users:
Since this is an upward-compatible extension, it may be ignored by
users.
Cost of Non-Adoption:
Occasional inconvenience and/or inefficiency.
Benefits:
Mathematical clarity.
Ability to do CLOS method dispatch on the type.
Aesthetics:
As mentioned under "rationale," this would be a more concise way to
express a common programming idiom.
Discussion:
The name "non-complex number" is incorrect because future
implementations may wish to include numerical types which are neither
complex nor real. [e.g. pure imaginary numbers or quaternions]
The name "scalar" is incorrect because the mathematical concept of
scalar may indeed include complex numbers.
Fortran and Pascal use the name "real" to mean what CL calls
SINGLE-FLOAT. That should cause no significant problem, since a Lisp
program written using the type REAL will do mathematically what the
equivalent Fortran program would do. This is because Fortran's "real"
data-type is a subtype of the CL REAL type. The only differences
might be that the Lisp program could be less efficient and/or more
accurate.
A survey of several Fortran and Pascal books shows that the distinction
between INTEGER and REAL is that REAL numbers may have fractional
parts, while INTEGERs do not. Later discussions explain that REALs
cover a greater range. Much later discussions cover precision
considerations, over/underflow, etc. So the average Fortran or Pascal
programmer should be completely comfortable with the proposed Lisp
concept of REAL.
∂17-Mar-89 0817 X3J13-mailer Issue: COERCE-INCOMPLETE (Version 3)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 08:17:09 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Fri, 17 Mar 89 10:56:55 EST
Date: Fri, 17 Mar 89 10:57 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: COERCE-INCOMPLETE (Version 3)
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Cc: masinter.pa@xerox.com, x3j13@sail.stanford.edu
In-Reply-To: <890316191820.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-Id: <19890317155747.8.BARMAR@OCCAM.THINK.COM>
Date: Thu, 16 Mar 89 19:18 EST
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Date: Thu, 16 Mar 89 18:00 EST
From: Barry Margolin <barmar@Think.COM>
...
Problem with DEPRECATE: Didn't we specify that the way to convert a
lambda expression into a function object is to use (COERCE x 'FUNCTION)?
Or did we also define a new function that does this?
Re-read FUNCTION-TYPE. The thing Beckerle really wanted and finally
got (over my objection) was that COERCE did nothing `hard' ... What
it ended up being able to be do can be expressed by #'IDENTITY and
#'SYMBOL-FUNCTION.
(COERCE x 'FUNCTION) ==
(ETYPECASE X
(SYMBOL (SYMBOL-VALUE X))
(FUNCTION X))
I don't really think anything more needs to be provided, even if we
DEPRECATE coerce.
I can't find my copy of FUNCTION-TYPE, but I remember it being amended
to add coercion of lambda expressions to functions. Maybe my memory is
faulty, but I remember something like
(COERCE X 'FUNCTION) ==
(ETYPECASE X
(SYMBOL (SYMBOL-FUNCTION X))
(FUNCTION X)
((SATISFIES LAMBDA-EXP-P) (EVAL `(FUNCTION ,X))))
(DEFUN LAMBDA-EXP-P (X)
(AND (CONSP X) ; a non-null list
(EQ (CAR X) 'LAMBDA) ; beginning with LAMBDA
(NOT (NULL (CDR X))) ; with at least two elements
(LISTP (CADR X)))) ; argument list is a list
barmar
∂17-Mar-89 0822 chandler@polya.Stanford.EDU test
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Mar 89 08:22:09 PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA19995; Fri, 17 Mar 89 08:19:38 -0800
Date: Fri, 17 Mar 1989 8:19:36 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: retreat@polya.Stanford.EDU
Subject: test
Message-Id: <CMM.0.87.606154776.chandler@polya.stanford.edu>
∂17-Mar-89 0834 X3J13-mailer Issue: LOCALLY-TOP-LEVEL (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 08:34:33 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 559504; Fri 17-Mar-89 11:31:57 EST
Date: Fri, 17 Mar 89 11:31 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOCALLY-TOP-LEVEL (Version 2)
To: X3J13@sail.stanford.edu
References: <19890309233609.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890317163159.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
This is a cleanup committee issue. It could have been in the
compiler committee, but as it happens it ended up in the
cleanup committee.
Issue: LOCALLY-TOP-LEVEL
References: None
Related issues: EVAL-WHEN-NON-TOP-LEVEL, DECLARATION-SCOPE
Category: CLARIFICATION / ADDITION
Edit history: Version 1, 9-Mar-89, by Moon
Version 2, 16-Mar-89, by Moon, fix referenced proposal name
Problem description:
It is desirable to be able to wrap LOCALLY around one or more
top-level forms and have them continue to be treated as top-level
forms. Three examples of how this is useful:
- to put an OPTIMIZE or INLINE declaration into force around
several related forms.
- to put declarations into force around DEFCLASS, or any other
top-level form that lacks a syntax for embedded declarations.
- DECLARATION-SCOPE:NO-HOISTING, which passed in January,
removed the ability to use a DECLARE at the head of the body of a
DEFUN or DEFMACRO to make a declaration that applies to the entire
form, including the lambda-list. We are supposed to use LOCALLY
instead, but forms in the body of LOCALLY are not top-level,
and that changes the semantics of DEFMACRO.
Issue EVAL-WHEN-NON-TOP-LEVEL could not define LOCALLY to treat
its body as top-level forms, because only a special form can do
that and LOCALLY is a macro.
Proposal (LOCALLY-TOP-LEVEL:SPECIAL-FORM):
Change LOCALLY from a macro to a special form, and change the
definition of compiler processing (in EVAL-WHEN-NON-TOP-LEVEL)
so that when a LOCALLY form appears at top level the forms in
its body are processed at top level.
Examples:
(locally (declare (optimize (safety 3) (space 3) (speed 0)))
(defmacro frob (&environment e x y &optional (z (foo x y)))
(mumble x y z e)))
Without this proposal, this would have to be written
(defmacro frob (&environment e x y &optional (z (locally
(declare
(optimize
(safety 3)
(space 3)
(speed 0)))
(foo x y))))
(locally (declare (optimize (safety 3) (space 3) (speed 0)))
(mumble x y z e)))
Rationale:
Wrapping LOCALLY around a form should not change its semantics except
as specified by the declarations, hence the body of a top-level
LOCALLY should be top-level.
A macro cannot have a top-level body unless it expands into a special
form that has a top-level body; otherwise the macro invocation and
the macro expansion would not have identical semantics as top-level
forms. There is no available special form for LOCALLY to macroexpand
into (CLtL doesn't say, but presumably the intent was to expand into
a LET with an empty binding list).
Current practice:
The Zetalisp equivalent of LOCALLY worked to surround top-level forms,
because it was a macro that expanded into COMPILER-LET (stashing the
declarations in a special variable the compiler would look at). This
is of course the wrong way to do declarations, but it shows that the
idea was that you could wrap declarations around a bunch of top-level
forms.
Symbolics Genera 7.4.0 does not implement the proposal (but it does
not implement DECLARATION-SCOPE:NO-HOISTING either). I did
not survey any other implementations.
Cost to Implementors:
A half dozen lines of code in the compiler and a smaller amount
in the interpreter and any program-analyzing programs.
Cost to Users:
None.
Cost of non-adoption:
See the horrible example above.
Performance impact:
None.
Benefits:
More consistent language.
Esthetics:
Improved.
Discussion:
None.
∂17-Mar-89 0854 X3J13-mailer Re: Issue: COERCE-INCOMPLETE (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 08:53:52 PST
Received: from Salvador.ms by ArpaGateway.ms ; 17 MAR 89 08:48:52 PST
Date: 17 Mar 89 08:47 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: COERCE-INCOMPLETE (Version 3)
In-reply-to: Barry Margolin <barmar@Think.COM>'s message of Fri, 17 Mar 89
10:57 EST
To: Barry Margolin <barmar@Think.COM>
cc: x3j13@sail.stanford.edu
Message-ID: <890317-084852-8321@Xerox>
I sent you a copy of FUNCTION-TYPE, as amended and passed. There was
discussion of an amendment to allow coercion of lambda expressions to
functions, but the decision at the June 88 X3J13 meeting was to not require
such coercions.
Most of the issues passed so far are available from arisia.xerox.com
clcleanup/passed. Some of the issues that were amended at the last meeting
haven't yet been stored 'as amended'. I hope to have them there in the next
few days, as well as copies of all of the 'pending' issues.
∂17-Mar-89 0857 X3J13-mailer Re: Issue: COERCE-INCOMPLETE (Version 3)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 17 Mar 89 08:57:27 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA01151; Fri, 17 Mar 89 09:54:54 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA06800; Fri, 17 Mar 89 09:54:37 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903171654.AA06800@defun.utah.edu>
Date: Fri, 17 Mar 89 09:54:35 MST
Subject: Re: Issue: COERCE-INCOMPLETE (Version 3)
To: Barry Margolin <barmar@Think.COM>
Cc: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>, masinter.pa@xerox.com,
x3j13@sail.stanford.edu
In-Reply-To: Barry Margolin <barmar@Think.COM>, Fri, 17 Mar 89 10:57 EST
BarMar is right. I have a hardcopy of the FUNCTION-TYPE writeup that
was mailed on 4 Sep 88, with a note from Larry indicating that it's
the final version as passed at the June meeting. It includes
COERCE'ing of lambda expressions to functions as item 6b.
Personally, I don't think this is a valid argument for not getting rid
of COERCE, since it is easy to coerce a lambda expression to a function
using (EVAL `(FUNCTION ,x)).
-Sandra
-------
∂17-Mar-89 0906 @Score.Stanford.EDU:golub@na-net.stanford.edu A High-Tech Research Agenda
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Mar 89 09:06:08 PST
Received: from honesty.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 17 Mar 89 09:02:34-PST
Received: by honesty.stanford.edu (4.0/inc-1.5)
id AA02205; Fri, 17 Mar 89 09:09:40 PST
Date: Fri, 17 Mar 89 09:09:40 PST
From: golub@na-net.stanford.edu (Gene Golub)
Message-Id: <8903171709.AA02205@honesty.stanford.edu>
To: faculty@score.stanford.edu
Subject: A High-Tech Research Agenda
The front page of the business page of today's New York Times lists a
"High-Tech Research Agenda", designated by the Department of Defense
and Department of Energy. Many of these 22 items are of direct
interest to the CS department. For instance, items 3,4, 5 and 6 are as
follows:
3. Software producibility
4. Parallel processing
5. Machine intelligence/robotics
6. Simulation
Many of the other items are also connected with this department.
Has anyone seen the full document?
Gene
∂17-Mar-89 0946 @Score.Stanford.EDU:csl@sierra.STANFORD.EDU CSD Faculty Candidate Seminar, March 21, 1989 at 10 a.m.
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Mar 89 09:46:49 PST
Received: from sierra.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Fri 17 Mar 89 09:09:48-PST
Received: by sierra.STANFORD.EDU (3.2/4.7); Fri, 17 Mar 89 09:08:34 PST
From: csl@sierra.STANFORD.EDU (Eileen Schwappach)
Date: Fri 17 Mar 89 09:08:32-PST
Subject: CSD Faculty Candidate Seminar, March 21, 1989 at 10 a.m.
To: CSL-EVERYONE@SIERRA, faculty@score, all-colloq@score
Cc: csl@SIERRA
Message-Id: <606157712.0.CSL@SIERRA>
Mail-System-Version: <SUN-MM(219)+TOPSLIB(128)@SIERRA>
CSD FACULTY SEARCH CANDIDATE
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Title: The Constraint-Based Paradigm:
The Integration of Rule-Based and Object-Oriented Programming
Speaker: Michael van Biema
From: Columbia University
Department of Computer Science
Place: MJH 252
Date: March 21, 1989 at 10:00 a.m.
ABSTRACT
This talk introduces a new formalism, the Constraint-Based paradigm, that
combines the Object-Oriented and Rule-Based paradigms in an elegant and
orthogonal way.
The Constraint-Based model is a generalization of traditional method invocation
in Object-Oriented programming that allows method discrimination on the basis
of arbitrary user-defined predicates. Languages based on the Object-Oriented
and Rule-Based paradigms have both been in existence for some time. Yet both
paradigms suffer from a few lingering problems that have been identified in the
literature. Constraint-Based invocation provides solutions for such problems
as multiple inheritance in Object-Oriented systems and the expression of
control in Rule-Based systems by uniting them in terms of constrained method
invocation. The single underlying representation of both rules and methods
also allows the expression of their resolution in terms of meta-methods.
An additional central philosophical argument of the talk is that so called
`multi-paradigm' languages should be developed not by combining paradigms into
a partially integrated system, but rather by their unification into a
synergistic language developed under a new, subsuming formal model.
-------
∂17-Mar-89 1041 X3J13-mailer Issue: PACKAGE-FUNCTION-CONSISTENCY, V.3
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 10:40:58 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 17 MAR 89 10:28:12 PST
Date: 17 Mar 89 10:25 PST
From: masinter.pa@Xerox.COM
Subject: Issue: PACKAGE-FUNCTION-CONSISTENCY, V.3
To: x3J13@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Message-ID: <890317-102812-1247@Xerox>
The notes from the January meeting said Accepted MORE-PERMISSIVE (v2),
as amended. Amendments made at the meeting added DELETE-PACKAGE and
DEFPACKAGE to the list of functions and removed the paragraph beginning
with the words "If IN-PACKAGE...".
I can't figure out where a package name *isn't* allowed in DEFPACKAGE
or where a package object would make sense. Are the notes incorrect,
or were we just to hasty?
Anyway, here's my guess at what we really meant to pass; I suppose
we can just vote this one in instead.
!
Issue: PACKAGE-FUNCTION-CONSISTENCY
References: 11.7 Package System Functions and Variables (pp182-188)
Category: CLARIFICATION/CHANGE
Edit history: 21-Oct-88, Version 1 by Pitman
12-Jan-89, Version 2 by Masinter (add MORE-PERMISSIVE option)
17-Mar-89, Version 3, by Masinter, MORE-PERMISSIVE as
amended & adopted at Jan 89 X3j13
Problem Description:
CLtL is vague about whether either or both of package or package name
are permissible in some cases.
Proposal (PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE):
Clarify that it is permissible to pass either a package object
or a package name (symbol or string) in the following situations:
- the :USE argument to MAKE-PACKAGE or IN-PACKAGE
- the first argument to IN-PACKAGE, FIND-PACKAGE, RENAME-PACKAGE
or DELETE-PACKAGE
- the second argument to INTERN, FIND-SYMBOL, UNINTERN
- the second argument to EXPORT, UNEXPORT, IMPORT,
SHADOWING-IMPORT, and SHADOW
- the first argument (or a member of the list which is the first
argument) to USE-PACKAGE or UNUSE-PACKAGE.
- the PACKAGE argument to DO-SYMBOLS.
- the PACKAGE argument to DO-EXTERNAL-SYMBOLS.
- the PACKAGE argument to DO-ALL-SYMBOLS.
If FIND-PACKAGE is given a package object as an argument, it simply
returns it.
Clarify that the functions PACKAGE-NAME, PACKAGE-NICKNAMES,
PACKAGE-USE-LIST, and PACKAGE-USED-BY-LIST are (at least conceptually)
accessors to package data structures and permit only package objects
as arguments.
Clarify that the function MAKE-PACKAGE permits only a package name
as an argument since it does not make sense to create an existing
package.
Clarify that package nicknames must always be expressed as package
names (symbols or strings) and may never be actual package objects.
In addition, require that PACKAGE-NAME, PACKAGE-NICKNAMES,
PACKAGE-USE-LIST, and PACKAGE-USED-BY-LIST to accept names,
too.
Examples:
(INTERN "FOO" "KEYWORD") => :FOO
(DEFVAR *FOO-PACKAGE* (MAKE-PACKAGE "FOO"))
(RENAME-PACKAGE "FOO" "FOO0")
(PACKAGE-NAME *FOO-PACKAGE*) => "FOO0"
(PACKAGE-NAME "SYS") might return "SYSTEM".
Rationale:
This makes things more consistent.
It also adds a generally useful capability.
Current Practice:
Symbolics Genera & Lucid permits strings as package names.
Symbolics Cloe does not permit strings as package names.
In Lucid FIND-PACKAGE and IN-PACKAGE require names.
Cost to Implementors:
Small.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Implementations would continue to vary gratuitously, leaving a potential
for portability problems.
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
This makes things more regular, and so presumably more aesthetic.
Discussion:
Pitman ran across this problem while trying to port Macsyma to various
implementations. Discussion with other maintainers of portable programs
shows this is a common source of aggravation in portable code.
Since the pathname accessors all take namestrings or streams, one might
easily argue that it would be more consistent for PACKAGE-NAME,
PACKAGE-NICKNAMES, etc. to also take arguments of package names. After
all,
(PACKAGE-NAME "FOO") => "FOO"
is no stranger than
(NAMESTRING "JOE:fred.lisp") => "JOE:fred.lisp".
It would be possible to say that MAKE-PACKAGE took package objects as
arguments and just returned that package. That might have limited
usefulness on rare occassions, but mostly seemed too far out in left
field to bother suggesting it.
∂17-Mar-89 1223 X3J13-mailer issue SAFE-CODE, version 1
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:22:54 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA01090g; Wed, 15 Mar 89 14:31:11 PST
Received: by challenger id AA12754g; Wed, 15 Mar 89 14:25:03 PST
Date: Wed, 15 Mar 89 14:25:03 PST
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8903152225.AA12754@challenger>
To: cl-compiler@sail.stanford.edu, x3j13@sail.stanford.edu
Subject: issue SAFE-CODE, version 1
According to my understanding of the dictionary definitions,
``unsafe'' means primarily ``the opposite or reversal of `safe' '' and
secondarily ``not safe.'' This coincides with Moon's reading.
Therefore, I propose we use the term ``nonsafe'' which clearly means
``not safe.'' This, coupled with the already very explicit definition
of ``unsafe,'' which explains that unsafe code might actually be safe,
should take care of his objection.
-rpg-
∂17-Mar-89 1223 X3J13-mailer **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:23:14 PST
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA00913g; Wed, 15 Mar 89 12:36:51 PST
Received: by blacksox id AA00297g; Wed, 15 Mar 89 12:40:06 PST
Date: Wed, 15 Mar 89 12:40:06 PST
From: Eric Benson <eb@lucid.com>
Message-Id: <8903152040.AA00297@blacksox>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-compiler@sail.stanford.edu, x3j13@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 14 Mar 89 18:41 EST <19890314234118.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Date: Tue, 14 Mar 89 18:41 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
This looks good so far. A few comments that might help you
along with the draft:
...
The :MACRO argument to AUGMENT-ENVIRONMENT shouldn't look like the CADR
of a MACROLET special form, instead it should be a list of lists (name
function). That is, the expander functions should be supplied in the
form of functions rather than in the form of the source text used by
MACROLET. Your rationale argues against this but I strongly believe
that the rationale is wrong. I wouldn't mind seeing the parsing portion
of MACROLET made available as a separate function.
A small point: Shouldn't this be an a-list of the form
(name . function) instead of a list of lists?
∂17-Mar-89 1223 X3J13-mailer Issue ERROR TERMINOLOGY
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:23:02 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA01029g; Wed, 15 Mar 89 14:13:57 PST
Received: by challenger id AA12685g; Wed, 15 Mar 89 14:07:47 PST
Date: Wed, 15 Mar 89 14:07:47 PST
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8903152207.AA12685@challenger>
To: x3j13@sail.stanford.edu
Subject: Issue ERROR TERMINOLOGY
Is it the case that ``fatal'' is well-defined? If so, ``harmless'' is
simply something that is not fatal. According to my mathematics
education, that renders the term well-defined.
``Indeed, there is no way to invoke GC in Common Lisp and with a few
exceptions such as messages, GC must have NO side effects.''
Unsolicited messages can happen, and there is a proposal on the
cl-editorial table to render them harmless. If GC can have no side
effects, then why not state that and not wonder about unsolicited
messages? If we did that, then any Common Lisp that does print a
progress note is *out* of conformance.
Also, as I've said several times, rehashing, termination of processes,
progress messages, flushing IO buffers, closing streams, and a list of
possibly hundreds of things are side effects of GC that should be
guaranteed harmless (that is, not fatal).
``> Some things are not immediately harmful but may cause
> trouble later on.
Yes, lots of things are that way.''
The definition of fatal puts no time constraints on the fatality. Therefore,
neither does its negation.
``> By ``unpredictable but harmless'', I think we are in effect saying
> ``not completely unpredictable''. That is, we promise something but
> don't quite say what it is. For example, Lisp will presumably not
> break off and start playing chess. But maybe it's harmless to start
> playing chess.''
The beauty of a specification is knowing what not to say in order to
allow rational interpreters the freedom to interpret rationality now
and in the unpredictable future. There is considerable genius in the
fine line that Steele tread in CLtL on this. Does anyone rationally
think that a Common Lisp would be taken seriously that while GCing
broke out in a game of chess or an Irish gig? I refuse to seriously
debate with anyone who would use that as an example of something that
we must utter one word in the specification to prevent.
``As far as I can see, the only reasonable option is to specify
some range of possible consequences. The constraints, whatever
they may be, make it possible to reason about what the program
will do.''
The reason this won't easily work is that it presumes that we are able
to accurately predict future implementation techniques and even to
fully comprehend current ones. I'm sure that KMP or I could supply an
endless stream of new and bizarre cases that have to be explicitly
dealt with. (I single out KMP because he has uncanny creativity.)
But, I'll change the debate a little. I've claimed that ``harmless''
is well-defined if and only if ``fatal'' is well-defined or at least
defined well enough. So, to convince me that ``harmless'' should be
pitched, you must convince me that ``fatal'' must be pitched.
-rpg-
∂17-Mar-89 1214 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:14:37 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01413g; Wed, 15 Mar 89 23:32:00 PST
Received: by bhopal id AA11607g; Wed, 15 Mar 89 23:32:47 PST
Date: Wed, 15 Mar 89 23:32:47 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8903160732.AA11607@bhopal>
To: cl-cleanup@sail.stanford.edu
Cc: X3J13@Sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 15 Mar 89 05:13 PST <890315-051405-3472@Xerox>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Although I haven't had time to join the overly-lengthy discussion on this
matter, I did point out one particularly confusing direction -- that this
proposal to "fix" the function ADJUST-ARRAY has become a proposal to alter
the semantics of the type SIMPLE-ARRAY. Compare CLtL, p28, with the
sentence in the Rationale Section:
"Specifying the points left unspecified (requiring all simple arrays to be
non-adjustable and all adjustable arrays to be non-simple) would require
large changes to some implementations and would be of little benefit to
..."
and with an item in the Clarification section:
"a. Whether an array can be both simple and adjustable is unspecified."
[CLtL definition *does* specify it].
I suggested that a simple statement be added to the proposal as follows:
"This proposal does not attempt to alter the meaning of the type
SIMPLE-ARRAY in any way"
Moon expressed approval of adding that statement.
Altered semantics would mean that it is no longer a portable type. I
have sent out several trivially small examples that show this. Some
people have interpreted those examples as simply showing what happens
with "broken" code; but quite to the contrary, they show how code can be
"correct" on one implementation and "broken" on another ****** when the
definition of SIMPLE-ARRAY is allowed to vary between one implementation
and the other ******. Very carefully, CLtL spells out that implementations
may vary on the efficiency with which they implement SIMPLE-ARRAYS; but
nowhere does it provide for optional exclusion of some parts of the
definition thereof.
Also, I note that all of the discussion on the Cl-cleanup list was by
persons other than the half-dozen or so maintainers of "stock hardware"
compilers. I personally spoke with three others (not including myself)
at Hawaii, and we all have identical requirements for the type SIMPLE-ARRAY,
and identical resolve that it must not be changed. Our compilers will
continue to offer this C-level optimization capability; the only
question is whether or not the CL1989 Standard will be cognizant of it.
-- JonL --
∂17-Mar-89 1246 X3J13-mailer Issue: PACKAGE-FUNCTION-CONSISTENCY, V.3
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:45:23 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Fri, 17 Mar 89 14:55:05 EST
Date: Fri, 17 Mar 89 14:46 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: PACKAGE-FUNCTION-CONSISTENCY, V.3
To: masinter.pa@xerox.com
Cc: x3J13@sail.stanford.edu
In-Reply-To: <890317-102812-1247@Xerox>
Message-Id: <19890317194641.7.BARMAR@OCCAM.THINK.COM>
Date: 17 Mar 89 10:25 PST
From: masinter.pa@xerox.com
Proposal (PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE):
Clarify that the functions PACKAGE-NAME, PACKAGE-NICKNAMES,
PACKAGE-USE-LIST, and PACKAGE-USED-BY-LIST are (at least conceptually)
accessors to package data structures and permit only package objects
as arguments.
...
In addition, require that PACKAGE-NAME, PACKAGE-NICKNAMES,
PACKAGE-USE-LIST, and PACKAGE-USED-BY-LIST to accept names,
too.
You can't have it both ways! Also, the grammar of the second one could
use improving.
barmar
∂17-Mar-89 1257 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:57:27 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Fri, 17 Mar 89 15:52:50 EST
Date: Fri, 17 Mar 89 15:53 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
To: Jon L White <jonl@lucid.com>
Cc: cl-cleanup@sail.stanford.edu, X3J13@sail.stanford.edu
In-Reply-To: <8903160732.AA11607@bhopal>
Message-Id: <19890317205329.0.BARMAR@OCCAM.THINK.COM>
What happens in implementations that allow all arrays to be adjusted?
If you require that (typep x 'simple-array) implies (not
(adjustable-array-p x)), I see two possible resolutions: 1) such
implementations are not conforming; 2) the type SIMPLE-ARRAY is empty.
I find (1) distasteful, because non-adjustable arrays and the
SIMPLE-ARRAY type exist solely for the benefit of implementations that
need them, and this would require support of these concepts in
implementations that don't derive any benefit from them. I think (2)
makes the SIMPLE-ARRAY type pretty useless, since a portable program
can't expect anything to be of this type (FIXNUM had this problem until
we fixed it in Hawaii).
barmar
∂17-Mar-89 1251 CL-Compiler-mailer **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:51:13 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 559802; Fri 17-Mar-89 15:48:20 EST
Date: Fri, 17 Mar 89 15:48 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
To: Eric Benson <eb@lucid.com>
cc: cl-compiler@sail.stanford.edu, x3j13@sail.stanford.edu
In-Reply-To: <8903152040.AA00297@blacksox>
Message-ID: <19890317204812.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 15 Mar 89 12:40:06 PST
From: Eric Benson <eb@lucid.com>
Date: Tue, 14 Mar 89 18:41 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
The :MACRO argument to AUGMENT-ENVIRONMENT shouldn't look like the CADR
of a MACROLET special form, instead it should be a list of lists (name
function).
A small point: Shouldn't this be an a-list of the form
(name . function) instead of a list of lists?
Oh, I keep forgetting that some people have to worry about the efficiency
of conses versus lists. I don't care which it is.
∂17-Mar-89 1254 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:54:39 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 559814; Fri 17-Mar-89 15:51:33 EST
Date: Fri, 17 Mar 89 15:51 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
To: Jon L White <jonl@lucid.com>
cc: cl-cleanup@sail.stanford.edu, X3J13@Sail.stanford.edu
In-Reply-To: <8903160732.AA11607@bhopal>
Message-ID: <19890317205125.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 15 Mar 89 23:32:47 PST
From: Jon L White <jonl@lucid.com>
Although I haven't had time to join the overly-lengthy discussion on this
matter, I did point out one particularly confusing direction -- that this
proposal to "fix" the function ADJUST-ARRAY has become a proposal to alter
the semantics of the type SIMPLE-ARRAY.
Adding the discussion of SIMPLE-ARRAY was at *+*YOUR*+* request, JonL.
There is !!NO!! change to the semantics, as I thought you had agreed in
the last message you sent on the topic. If now you're taking that back
and saying that you still think what this proposal says is a change to
the semantics, okay, but I have yet to figure out why you think that or
what you think is changed.
∂17-Mar-89 1316 X3J13-mailer Issue DYNAMIC-EXTENT: a remark
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 13:15:31 PST
Received: from fafnir.think.com by Think.COM; Fri, 17 Mar 89 14:55:24 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 17 Mar 89 14:54:21 EST
Received: by verdi.think.com; Fri, 17 Mar 89 14:51:09 EST
Date: Fri, 17 Mar 89 14:51:09 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903171951.AA09006@verdi.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: gls@Think.COM, masinter.pa@xerox.com, X3J13@sail.stanford.edu
In-Reply-To: David A. Moon's message of Thu, 16 Mar 89 17:15 EST <19890316221519.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue DYNAMIC-EXTENT: a remark
Date: Thu, 16 Mar 89 17:15 EST
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Line-Fold: No
Date: Thu, 16 Mar 89 15:34:53 EST
From: Guy Steele <gls@Think.COM>
A "proper
part" of an object A is any object that is accessible at the beginning
of the scope of the declaration -only- by applying a function to A or to
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
a "proper part" of A. This means that any objects freshly allocated
during the construction of the initial value of the declared variable,
and not "saved" during the construction of that value, are "proper
parts" and can be allocated on a stack.
I believe that the words indicated above should be replaced by
"the extent of the binding for which the delaration was made".
That would change the meaning, since the declaration might not be attached
to a binding.
I am not certain that I understand the meaningful uses of this declaration
in cases where it is not attached to a binding.
The reference appears to be to a point in time. Scopes are in space;
the beginning of a scope is a character position in the text (or
something like that). Extents are in time. Is this what you meant?
You're right that there is something wrong with this wording. How about
if it said "at the beginning of execution of the forms in the scope of
the declaration"? Do declarations have extents? If so, could it say
"at the beginning of the extent of the declaration"?
I think you have to speak in terms of run-time instantiations
of executable code. Not sure.
--Guy
∂17-Mar-89 1356 CL-Compiler-mailer **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 13:54:27 PST
Received: from fafnir.think.com by Think.COM; Fri, 17 Mar 89 16:48:54 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 17 Mar 89 16:50:04 EST
Received: by verdi.think.com; Fri, 17 Mar 89 16:46:51 EST
Date: Fri, 17 Mar 89 16:46:51 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903172146.AA09535@verdi.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: eb@lucid.com, cl-compiler@sail.stanford.edu, x3j13@sail.stanford.edu
In-Reply-To: David A. Moon's message of Fri, 17 Mar 89 15:48 EST <19890317204812.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Date: Fri, 17 Mar 89 15:48 EST
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Date: Wed, 15 Mar 89 12:40:06 PST
From: Eric Benson <eb@lucid.com>
Date: Tue, 14 Mar 89 18:41 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
The :MACRO argument to AUGMENT-ENVIRONMENT shouldn't look like the CADR
of a MACROLET special form, instead it should be a list of lists (name
function).
A small point: Shouldn't this be an a-list of the form
(name . function) instead of a list of lists?
Oh, I keep forgetting that some people have to worry about the efficiency
of conses versus lists. I don't care which it is.
Well, don't forget PAIRLIS and ACONS, which make the CONS format
a little easier to use than the LIST format.
[Voice 1: AAAAHHHHH!!! No!!! Not FORMAT!!!]
Calm down; I meant it generically. Make that "organization".
[Voice 2: AUUGUGGHH! Not generics!]
--Guy
∂17-Mar-89 1507 @Score.Stanford.EDU:jutta@coyote.stanford.edu Seminar by Robotics Faculty Candidate
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Mar 89 15:07:44 PST
Received: from coyote.stanford.edu by SCORE.STANFORD.EDU with TCP; Fri 17 Mar 89 15:04:12-PST
Received: by coyote.stanford.edu; Fri, 17 Mar 89 15:09:29 PST
Date: 17 Mar 1989 1509-PST (Friday)
From: Jutta McCormick <jutta@coyote.stanford.edu>
To: cedar@coyote.stanford.edu, faculty@score.Stanford.EDU,
davis@score.Stanford.EDU, cannon@sierra.Stanford.EDU,
bxr@sail.Stanford.EDU, myers@polya.Stanford.EDU
Cc:
Subject: Seminar by Robotics Faculty Candidate
SPECIAL ROBOTICS SEMINAR
Speaker: Michael Erdmann
M.I.T.
Title: MOTION PLANNING WITH UNCERTAINTY: A PROBABILISTIC APPROACH
Date: Monday, March 20, 1989
Time: 4:00 p.m.
Place: Cedar Hall Conference Room
ABSTRACT
Robots must successfully solve tasks in the presence of uncertainty.
Uncertainty arises from errors in sensing, modelling, and control. In
the past much work has been directed towards finding strategies that
are guaranteed to succeed in a specific number of steps. This talk
presents an alternative approach: The purposeful injection of randomized
actions in a strategy. Randomized actions are useful in a variety of
settings. For instance, a random motion can make progress even when
sensory information is inadequate to decide on the next proper course
of action. In some settings a randomized action may be preferable to an
action that is guaranteed to be successful but that requires too much
computational effort or execution time.
In this talk I will present a few examples involving randomized
actions. I will mention implementations of the theory, both in
simulation and on a physical manipulator. I will also discuss the
relationship of randomized strategies to the pre-image framework
developed by Lozano-Perez, Mason, and Taylor for generating guaranteed
strategies.
∂17-Mar-89 1426 X3J13-mailer CLTL II
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 14:24:50 PST
Received: from fafnir.think.com by Think.COM; Fri, 17 Mar 89 17:20:09 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 17 Mar 89 17:21:19 EST
Received: by verdi.think.com; Fri, 17 Mar 89 17:18:06 EST
Date: Fri, 17 Mar 89 17:18:06 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903172218.AA09852@verdi.think.com>
To: x3j13@sail.stanford.edu
Cc: gls@Think.COM
Subject: CLTL II
I have mailed copies of my current working draft of "CLTL II" to
nearly everyone on the X3J13 mailing list (defined to be the set of
mailing labels Bob Mathis sent me). Those of you in the US can expect
to receive them on Monday or Tuesday via UPS, except for the three of
you whose address is a P.O. Box, in which case you are at the mercy of
Priority SnailMail. I don't know how long it will take for
international delivery.
To keep the costs down, where two persons were at the same address or
organization, I sent only one copy; for three or more I generally sent
two copies. (In all I sent out 70 copies, at about 30 bucks each
including shipping.)
KMP points out that it would be a serious mistake for everyone to drop
everything and start reading this draft, and I agree. It is more
important to prepare for the upcoming meeting. Furthermore, I would
hate to see anyone burn out reading this less-than-authoritative draft
of a less-than-authoritative book and then not have the energy to give
the draft standard a careful reading as well.
You don't *have* to read it at all. If you don't have the time, then
use it as a doorstop, keep it as a souvenir, or give it to someone
like a graduate student.
I will be grateful for any feedback I can get, of course. I recommend
that you pay the most attention to my paraphrasing of and commentary
on issues with which you have been particularly involved, to make sure
I didn't goof it up. There is an index to the issues in the back that
may be helpful.
Some of the new material has nothing whatsoever to do with X3J13.
You may wish to check out the I/O and Numbers chapters, for example.
Digital Press will have a copy editor reading it for grammar and
punctuation, and I will be reading it carefully, so if your time
is limited you probably should concentrate on the conceptual level.
I am especially interested in feedback of the form "You're going about
this all wrong. Here's what you should do..."
Don't worry at all about fonts, spacing, or number of pages. What I
shipped to you today is merely 300-dots-per-inch draft quality with
the wrong fonts. I am meeting next week with the book designer at
Digital Press and we are going to work out what to do. I also have a
list of changes to make to my TeX macros that will systematically
improve the spacing and page break decisions.
--Guy
∂17-Mar-89 1541 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 15:40:34 PST
Received: from fafnir.think.com by Think.COM; Fri, 17 Mar 89 16:23:16 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 17 Mar 89 16:24:05 EST
Received: by verdi.think.com; Fri, 17 Mar 89 16:20:53 EST
Date: Fri, 17 Mar 89 16:20:53 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903172120.AA09400@verdi.think.com>
To: jonl@lucid.com
Cc: cl-cleanup@sail.stanford.edu, X3J13@sail.stanford.edu
In-Reply-To: Jon L White's message of Wed, 15 Mar 89 23:32:47 PST <8903160732.AA11607@bhopal>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Date: Wed, 15 Mar 89 23:32:47 PST
From: Jon L White <jonl@lucid.com>
...
Also, I note that all of the discussion on the Cl-cleanup list was by
persons other than the half-dozen or so maintainers of "stock hardware"
compilers. I personally spoke with three others (not including myself)
at Hawaii, and we all have identical requirements for the type SIMPLE-ARRAY,
and identical resolve that it must not be changed. Our compilers will
continue to offer this C-level optimization capability; the only
question is whether or not the CL1989 Standard will be cognizant of it.
I am very concerned about the stock hardware, but also very confused.
I understand that the stock-hardware implementors adamantly oppose
the proposed change, but I still have not seen a single convincing
example of why the proposed change would prevent them from accomplishing
the desired optimizations or why the proposed change would defeat
portability. I acknowledge that JonL has provided an example or two,
but I have not found them convincing. So either these examples are
wrong, or I am badly wedged; in either case I need further explanation.
--Guy
∂17-Mar-89 1555 X3J13-mailer Re: Issue: COERCE-INCOMPLETE (Version 3)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 15:55:11 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Fri, 17 Mar 89 18:48:21 EST
Date: Fri, 17 Mar 89 18:48 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Re: Issue: COERCE-INCOMPLETE (Version 3)
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
Cc: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>, masinter.pa@xerox.com,
x3j13@sail.stanford.edu
In-Reply-To: <8903171654.AA06800@defun.utah.edu>
Message-Id: <19890317234839.3.BARMAR@OCCAM.THINK.COM>
Date: Fri, 17 Mar 89 09:54:35 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Personally, I don't think this is a valid argument for not getting rid
of COERCE, since it is easy to coerce a lambda expression to a function
using (EVAL `(FUNCTION ,x)).
I disagree. Many of us would not have voted in favor of FUNCTION-TYPE
without the coercion. We wanted either a specific function or the
extension to COERCE. We specifically did not feel that the above idiom
should be used in any actual code; it merely serves as a good way of
describing the value that the coercion returns.
I'll go along with COERCE-INCOMPLETE:DEPRECATE if it is amended to
include a new function that coerces a lambda expression, symbol, or
function to a function. I'll even suggest a name: MAKE-FUNCTION
(unfortunately, FUNCTION is taken, so it can't follow the precedent of
naming a function that coerces to type T just T).
barmar
∂17-Mar-89 1600 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89 16:00:33 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02088g; Fri, 17 Mar 89 15:53:13 PST
Received: by bhopal id AA19366g; Fri, 17 Mar 89 15:55:29 PST
Date: Fri, 17 Mar 89 15:55:29 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8903172355.AA19366@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@sail.stanford.edu, X3J13@Sail.stanford.edu
In-Reply-To: David A. Moon's message of Fri, 17 Mar 89 15:51 EST <19890317205125.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
re: Adding the discussion of SIMPLE-ARRAY was at *+*YOUR*+* request, JonL.
Sorry, Dave, I only ever made a request to add precisely the one statement
that you have already now added -- that the proposal *does not* alter
the CLtL semantics of SIMPLE-ARRAY. What I critiqued were statements
of the proposal that under reasonable interpretation could be taken to
mean that the CLtL p.28 definition of SIMPLE-ARRAY is being abrogated.
At any rate, thanks for the one-line addition.
-- JonL --
∂17-Mar-89 1612 X3J13-mailer Re: Issue: COERCE-INCOMPLETE (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 16:12:34 PST
Received: from Salvador.ms by ArpaGateway.ms ; 17 MAR 89 16:02:36 PST
Date: 17 Mar 89 15:57 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: COERCE-INCOMPLETE (Version 3)
In-reply-to: masinter.pa's message of 17 Mar 89 08:47 PST
To: masinter.pa@Xerox.COM
cc: Barry Margolin <barmar@Think.COM>, x3j13@sail.stanford.edu
Message-ID: <890317-160236-2538@Xerox>
Sorry, I was confused when I sent that message. Yes, COERCE coerces lambda
expressions to functions. No, APPLY and FUNCALL do not (are not required
to)
do such coercions.
∂17-Mar-89 1613 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89 16:13:52 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02119g; Fri, 17 Mar 89 16:06:33 PST
Received: by bhopal id AA19436g; Fri, 17 Mar 89 16:08:50 PST
Date: Fri, 17 Mar 89 16:08:50 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8903180008.AA19436@bhopal>
To: barmar@Think.COM
Cc: cl-cleanup@sail.stanford.edu, X3J13@sail.stanford.edu
In-Reply-To: Barry Margolin's message of Fri, 17 Mar 89 15:53 EST <19890317205329.0.BARMAR@OCCAM.THINK.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
re: I find (1) distasteful, because non-adjustable arrays and the
SIMPLE-ARRAY type exist solely for the benefit of implementations that
need them, and this would require support of these concepts in
implementations that don't derive any benefit from them.
Barry, SIMPLE-ARRAY is certainly not the only concept in CLtL that exists
"solely for the benefit of implementations that [can really use it]". I
know that numerous array capabilities are present but not very useful
in Lucid Common Lisp primarily for compatiblity with Lisp Machine stuff.
That's the price to pay for portability. It just may be that we will have
to confess that we didn't succeed at portability in some areas of CL.
-- JonL --
∂17-Mar-89 1623 X3J13-mailer Issue: PACKAGE-FUNCTION-CONSISTENCY, V.3
Received: from YUKON.SCRC.Symbolics.COM (SCRC-YUKON.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 16:23:09 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 439582; Fri 17-Mar-89 19:22:26 EST
Date: Fri, 17 Mar 89 19:20 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-FUNCTION-CONSISTENCY, V.3
To: masinter.pa@Xerox.COM
cc: x3J13@sail.stanford.edu
In-Reply-To: <890317-102812-1247@Xerox>
Message-ID: <19890318002018.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 17 Mar 89 10:25 PST
From: masinter.pa@Xerox.COM
The notes from the January meeting said Accepted MORE-PERMISSIVE (v2),
as amended. Amendments made at the meeting added DELETE-PACKAGE and
DEFPACKAGE to the list of functions and removed the paragraph beginning
with the words "If IN-PACKAGE...".
I can't figure out where a package name *isn't* allowed in DEFPACKAGE
or where a package object would make sense. Are the notes incorrect,
or were we just to hasty?
It wasn't my amendment, but I don't see why a package object should be
disallowed in any position in DEFPACKAGE other than the name or nickname
of the package being defined. I'll send a version that I think is correct
to CL-Cleanup and if no one disagrees it can be mailed to X3J13 to
supersede this one.
∂17-Mar-89 1656 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 16:56:32 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Fri, 17 Mar 89 19:52:28 EST
Date: Fri, 17 Mar 89 19:53 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
To: Jon L White <jonl@lucid.com>
Cc: cl-cleanup@sail.stanford.edu, X3J13@sail.stanford.edu
In-Reply-To: <8903180008.AA19436@bhopal>
Message-Id: <19890318005322.4.BARMAR@OCCAM.THINK.COM>
Date: Fri, 17 Mar 89 16:08:50 PST
From: Jon L White <jonl@lucid.com>
re: I find (1) distasteful, because non-adjustable arrays and the
SIMPLE-ARRAY type exist solely for the benefit of implementations that
need them, and this would require support of these concepts in
implementations that don't derive any benefit from them.
Barry, SIMPLE-ARRAY is certainly not the only concept in CLtL that exists
"solely for the benefit of implementations that [can really use it]". I
know that numerous array capabilities are present but not very useful
in Lucid Common Lisp primarily for compatiblity with Lisp Machine stuff.
That's the price to pay for portability. It just may be that we will have
to confess that we didn't succeed at portability in some areas of CL.
-- JonL --
The general rule has been that implementations that don't need (or don't
provide) these types of optimizations can safely ignore the language
features that support them. Some implementations can optimize array
access by knowing that the array can't be adjusted; other
implementations should not be required to remember this information if
they don't need it. Quoting from CLtL: "features that are useful only
on certain 'ordinary' or 'commercial' processors are avoided or made
optional."
Any feature of the language that provides access to facets of the
implementation allows somewhat non-portable code, meaning that it is
possible to write conforming code that produces different results in
different implementations. The simple program (PROGN
MOST-POSITIVE-FIXNUM) is conforming but produces many different results,
although the program (TYPEP MOST-POSITIVE-FIXNUM 'FIXNUM) is guaranteed
to return T in all conforming implementations. To paraphrase Moon, it
would be wonderful if all conforming programs were portable, but that's
unrealistic (it would be like expecting the grammar of a language to
only permit sensible sentences to be formed -- I suspect Godel's
Incompleteness Theorem comes into play here, pointing out that if the
grammar allows you to say everything you'd want to say, it must also
include some nonsense). The best I think we can do is provide enough
tools in the language to allow programs to detect implementation
differences and deal with them.
One thing that would help me is if you would post an example of code
that you feel is affected by this issue. I think you described such
things to me in words at the last meeting, but I (like GLS) am having a
hard time figuring out precisely what the problem is (I had the same
difficulty with the FIXNUM stuff that started the moby flame session in
the car on the way to the Japanese restaurant).
barmar
∂17-Mar-89 1758 X3J13-mailer too much mail!
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 17 Mar 89 17:58:23 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA21950; Fri, 17 Mar 89 18:56:10 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA07465; Fri, 17 Mar 89 18:56:08 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903180156.AA07465@defun.utah.edu>
Date: Fri, 17 Mar 89 18:56:07 MST
Subject: too much mail!
To: x3j13@sail.stanford.edu
Hey folks, I have a request. If you want to discuss an issue from one
of the subcommittees that was mailed to X3J13, please try to confine
the discussion to the appropriate subcommittee mailing list (or even
private mail to the person you're arguing with) instead of CC'ing all
of X3J13. Some of us have been getting hundreds of mail messages a
day and I (at least) don't have the time to follow all of the detailed
arguments on issues from other subcommittees anyway. I'd like to know
what the resolution of the problems is, but I don't really need to get
a blow-by-blow account in the meantime.
You will be getting such a summary (and some revised proposals) from
cl-compiler around the end of next week, by the way.
-Sandra
-------
∂17-Mar-89 2051 X3J13-mailer March meeting issues and sections
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 17 Mar 89 20:51:38 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA16495; Fri, 17 Mar 89 10:21:57 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA16495; Fri, 17 Mar 89 10:21:57 PST
Message-Id: <8903171821.AA16495@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for skona%csilvax@hub.ucsb.edu; id AA16495; Fri, 17 Mar 89 10:21:57 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 17 Mar 89 13:00
To: x3j13@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: March meeting issues and sections
Dear Members:
The issues and sections of the standard named below have been
mailed to the X3J13 mailing list electronically and by hardcopy.
Also, the sections are available in files named march-1.dvi (chapter 1),
march-2.dvi (sections 2.1 and 2.2), march-5.dvi (chapter5), and
march-27-ballot.dvi (all the above-listed sections). Those files are
on hudson.dec.com, as usual, and the sources are there.
These issues and sections will come to vote on March 30
during the X3J13 meeting.
An affirmative vote on a section of the standard means that you
agree with the contents of the section except possibly the following:
Indentation of examples.
Spelling and other typos.
Figure placement and design.
The physical presence of issue markers (these will be removed in
the final draft); the issue markers sometimes change the indentation.
In addition, sections of the standard that could be modified by issues
passed by X3J13 that haven't been included up to this point, or have
been incorrectly included or under-included, will change even after
an affirmative vote on the section.
You are seeing two items again that appeared on the letter ballot:
ERROR-TERMINOLOGY, and Section 1.8. These were significantly changed
as a result of comments and will therefore require reviewing and
revoting.
On the front cover of each chapter that is part of this mailing (chapters 1, 2,
and 5) is a list headed by Reviewed by:. The people on this list
have simply READ and COMMENTED ON the attached sections. The appearance
of their names on the list is not an indication
of their endorsement, although they may in fact endorse the section they
reviewed.
Following is a summary of each issue and section's review history:
ERROR-TERMINOLOGY -- This issue was last revised by RPG, Moon, and
Pitman, and now they seem to be satisfied with the wording. This proposal is
directly reflected in Section 5.1.
CONFORMANCE-POSITION -- See the discussion section of this issue.
The issue is directly reflected in Section 1.5.
SUBSETTING-POSITION -- This issue has received general approval.
EXTENSIONS-POSITION -- Some would prefer we remain mute on this
issue, but the fact is that we have to provide some sort of definition
of an extension since we use the term in the ERROR-TERMINOLOGY proposal
and in the standard.
EXTRA-SYNTAX -- This issue has not received much comment until
recently. A new revised version may be distributed at the meeting.
EXTRA-OPTIONAL-KEYWORD-ARGUMENTS -- Mixed reviews on this proposal.
EXTRA-RETURN-VALUES -- Not much discussion on this proposal although
it appears to be generally accepted. (Version 3, that is)
UNSPECIFIED-DATATYPES -- This proposal seems to be generally opposed.
UNSOLICITED-MESSAGES -- This issue has not received much comment
until recently. A revised version may be necessary.
MACRO-AS-FUNCTION -- Moon suggests that we just change the two
macros in question to functions (and skip the proposal?).
Sections 1.1-1.7 -- Some of these sections depend on the passage
of the previously-listed proposals. These sections have been reviewed
by numerous people and their comments have been included.
In addition, some suggestions for moving some of these sections
to an appendix are being entertained. That is covered in the TOC
issue which may undergo slight amendment at the meeting.
Sections 2.1-2.2 -- These sections have also been reviewed by
numerous people, and comments were included. The main unresolved
issues with section 2.2 seem to be as follows:
Lack of integration with CLOS and the Condition System.
Lack of a good definition of the type function.
These issues will most likely be resolved via clean-up proposals.
Sections 5.1-5.4 -- Section 5.1 is a rewrite of the concepts
part of the Condition System document approved by X3J13. It was reviewed in
detail by KMP, and also by Sandra Loosemore. The other sections were
reviewed by numerous people.
Section 1.8 -- This section was sent out with the letter ballot.
Although the section was intended to be non-detailed, it was apparently
much too vague to make it useful. It has been made slightly more detailed,
and whether or not it is at a suitable level will be decided by you.
A suggestion was made to move this section to an appendix.
If you need electronic copies of any of the issues, please let me know
(although they will be coming to you in hardcopy soon). If you have
any trouble accessing the standard sections, there are other ways
besides FTP and hardcopy for you to get the standard. If I don't know
you're having trouble, though, I can't help you resolve the problem.
Thanks in advance for all your review time so far. Your comments and
suggestions are immensely useful.
kathy chapman
∂17-Mar-89 2110 X3J13-mailer Issue: EXTRA-RETURN-VALUES (version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 21:10:01 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560236; Sat 18-Mar-89 00:07:10 EST
Date: Sat, 18 Mar 89 00:06 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXTRA-RETURN-VALUES (version 3)
To: chapman%aitg.DEC@decwrl.dec.com
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903160834.AA18011@decwrl.dec.com>
Message-ID: <19890318050654.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
I would support this if it were amended with a list of functions
that are explicitly allowed to have additional return values.
As a suggested rough cut at such a list, how about all the functions
described in chapters 16, 21, 22, 23, 24, and 25 of CLtL? These are
the functions that I would call "environment" rather than "language".
∂17-Mar-89 2304 X3J13-mailer Issue: PACKAGE-FUNCTION-CONSISTENCY (version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 23:03:59 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560302; Sat 18-Mar-89 02:00:54 EST
Date: Sat, 18 Mar 89 02:00 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-FUNCTION-CONSISTENCY (version 4)
To: X3J13@sail.stanford.edu
Message-ID: <19890318070046.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
This is a correction to some wording problems and inconsistencies
in version 3 that was mailed out yesterday.
!
Issue: PACKAGE-FUNCTION-CONSISTENCY
References: 11.7 Package System Functions and Variables (pp182-188)
Category: CLARIFICATION/CHANGE
Edit history: 21-Oct-88, Version 1 by Pitman
12-Jan-89, Version 2 by Masinter (add MORE-PERMISSIVE option)
17-Mar-89, Version 3, by Masinter, MORE-PERMISSIVE as
amended & adopted at Jan 89 X3j13
17-Mar-89, Version 4, by Moon, correct amended wording
Problem Description:
CLtL is vague about whether either or both of package or package name
are permissible in some cases.
Proposal (PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE):
Clarify that it is permissible to pass either a package object
or a package name (symbol or string) in the following situations:
- the :USE argument to MAKE-PACKAGE or IN-PACKAGE
- the first argument to IN-PACKAGE, FIND-PACKAGE, RENAME-PACKAGE
or DELETE-PACKAGE
- the second argument to INTERN, FIND-SYMBOL, UNINTERN
- the second argument to EXPORT, UNEXPORT, IMPORT,
SHADOWING-IMPORT, and SHADOW
- the first argument (or a member of the list which is the first
argument) to USE-PACKAGE or UNUSE-PACKAGE.
- all package-name arguments in DEFPACKAGE except for the name and
nicknames of the package being defined.
- the first argument to PACKAGE-NAME, PACKAGE-NICKNAMES,
PACKAGE-USE-LIST, or PACKAGE-USED-BY-LIST
- the PACKAGE argument to DO-SYMBOLS.
- the PACKAGE argument to DO-EXTERNAL-SYMBOLS.
- the PACKAGE argument to DO-ALL-SYMBOLS.
If FIND-PACKAGE is given a package object as an argument, it simply
returns it.
Clarify that the function MAKE-PACKAGE permits only a package name
as an argument since it does not make sense to create an existing
package.
Clarify that package nicknames must always be expressed as package
names (symbols or strings) and may never be actual package objects.
In the list above, IN-PACKAGE may be changed to SELECT-PACKAGE
if IN-PACKAGE-FUNCTIONALITY:NEW-MACRO passes.
Examples:
(INTERN "FOO" "KEYWORD") => :FOO
(DEFVAR *FOO-PACKAGE* (MAKE-PACKAGE "FOO"))
(RENAME-PACKAGE "FOO" "FOO0")
(PACKAGE-NAME *FOO-PACKAGE*) => "FOO0"
(PACKAGE-NAME "SYS") might return "SYSTEM".
Rationale:
This makes things more consistent.
It also adds a generally useful capability.
Current Practice:
Symbolics Genera & Lucid permit strings as package names.
Symbolics Cloe does not permit strings as package names.
In Lucid FIND-PACKAGE and IN-PACKAGE require names.
Cost to Implementors:
Small.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Implementations would continue to vary gratuitously, leaving a potential
for portability problems.
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
This makes things more regular, and so presumably more aesthetic.
Discussion:
Pitman ran across this problem while trying to port Macsyma to various
implementations. Discussion with other maintainers of portable programs
shows this is a common source of aggravation in portable code.
It would be possible to say that MAKE-PACKAGE took package objects as
arguments and just returned that package. That might have limited
usefulness on rare occasions, but mostly seemed too far out in left
field to bother suggesting it.
∂18-Mar-89 0137 X3J13-mailer The Cleanup Issue Status List
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 18 Mar 89 01:37:09 PST
Received: from Semillon.ms by ArpaGateway.ms ; 18 MAR 89 01:34:10 PST
Date: 18 Mar 89 01:33 PST
From: masinter.pa@Xerox.COM
to: X3J13@sail.stanford.edu
Subject: The Cleanup Issue Status List
Message-ID: <890318-013410-3635@Xerox>
This is the complete list of Cleanup issues that are either:
passed: passed at *any* previous meeting, including Jan 89
pending: have been distributed for the March meeting
in progress: might possibly be distributed for the March meeting,
or that I think are worth pursuing.
Of course, some more might come up or be revived.
I think I have updated versions of all pending and passed
issues stored on arisia.xerox.com under the
clcleanup/pending
clcleanup/passed
directories respectively.
I'm pretty much unavailable (travelling, etc.) until the meeting.
I'll try to read my mail while on the road, but
it will be difficult to handle the quantity we've
seen in the last week.
Codes:
! released for Jan 89 meeting
+ passed
* need new version
!*: released, but I know we'll need a new version
+*: passed, but need to reconsider
!*: passed, but need a new version to reconsider
!
+ ADJUST-ARRAY-DISPLACEMENT
Version 4, 23-Nov-87
Status: passed, 1988
+ ADJUST-ARRAY-FILL-POINTER
Version 1, 15-MAR-88
Status: passed, 1988
! ADJUST-ARRAY-NOT-ADJUSTABLE
Synopsis: ADJUST-ARRAY on array made with :ADJUSTABLE NIL: "an error"?
Version 4, 11-Jan-89, Released 12-Jan-89
Status: Accepted with amendments Jan 89 X3J13
Comments: amendment had wording problem.
Version 8, 11-Mar-89, Released 15-Mar-89
Status: ready for vote
+ APPLYHOOK-ENVIRONMENT
Synopsis: remove (useless) env argument to applyhook
Version 2, 10-Jan-89, Released 10-Jan-89
Status: Passed Jan-89 X3J13
+ AREF-1D
14-NOV-87, Version 7
Status: Passed, 1988?
+ ARGUMENTS-UNDERSPECIFIED
Synopsis: Clarify various ranges missing from CLtL
Version 4, 21-Sep-88, Released 4 Dec 88
Status: Passed Jan 89 X3J13
+ ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Synopsis: What do array element-type declarations mean?
Version 9, 31-Oct-88, Released 5 Dec 88
Status: Passed Jan 89 X3J13
+ ASSOC-RASSOC-IF-KEY
Version 4, 23-NOV-87
Status: Passed, 1988?
! BREAK-ON-WARNINGS-OBSOLETE
Synopsis: deprecate *BREAK-ON-WARNINGS* because of *BREAK-ON-SIGNALS*
Version 1, 07-Mar-89, Released 15-Mar-89
Comment: leaves out a case
Status: ready for vote
! CLOS-CONDITIONS
Version 4, 10-Mar-89
Comments: define metaclass of conditions?
Status: pending
+ CLOSE-CONSTRUCTED-STREAMS
Synopsis: What does it mean to CLOSE a constructed stream?
Version 2, 12-Jan-89, Released 12-Jan-89
Status: Proposal ARGUMENT-STREAM-ONLY passed Jan 89 X3J13
!+ CLOSED-STREAM-OPERATIONS
Synopsis: What operations are legal on closed streams?
Version 5, 5-Dec-88, released 5-Dec-88
Status: amended at meeting
Version 7, 14-Feb-89
Status: Passed, as amended, Jan 89 X3J13
Comment: amendment bad; reconsider version 5.
say that INPUT-STREAM-P and OUTPUT-STREAM-P
are undefined on closed streams?
! COERCE-INCOMPLETE
Synopsis: Extend COERCE
Version 3, 7-Mar-89, Released 14-Mar-89
Status: ready for voting
+ COLON-NUMBER
Synopsis: :123 is an error
22-OCT-87, Version 1
Status: Passed, 1988?
+ COMPILER-WARNING-STREAM
Version 6, 5-JUN-87
Status: Passed, 1988?
+ COMPLEX-ATAN-BRANCH-CUT
Synopsis: tweak upper branch cut in ATAN formula
Version 1, 13-Dec-88, Released 10-Jan-89
Status: Passed Jan 89 X3J13
!* CONDITION-RESTARTS
Synopsis: can't know whether restart is associated with signalling
Version 1, 18-Jan-89, released 16-Mar-89
Comment: (proposed amendments)
Status: need new version
+ CONTAGION-ON-NUMERICAL-COMPARISONS
Version 1, 14-Sep-88, Released 6 Oct 88
Status: passed, Jan 89 X3J13
! COPY-SYMBOL-COPY-PLIST
Version 1, 10-Jan-89, released 16-Mar-89
Status: ready for vote
! COPY-SYMBOL-PRINT-NAME
Version 2, 15-Mar-89, released 16-Mar-89
Status: ready for vote
+ DATA-TYPES-HIERARCHY-UNDERSPECIFIED
4-SEP-88 Version 2
Status: Passed, 1988?
+ DECLARATION-SCOPE
Version 4, 15-Nov-88, Released 9-Dec-88
Status: NO-HOISTING passed Jan 89 X3J13
+ DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
Version 3, 13-Jan-89
Status: passed, Jan 89 X3J13
+ DECLARE-FUNCTION-AMBIGUITY
Version 4, 5-Dec-88, Released 5-Dec-88
Status: passed, Jan 89 X3J13
+ DECLARE-MACROS
5-FEB-88, Version 3
Status: Passed, 1988?
+ DECLARE-TYPE-FREE
Version 10, 12-Jan-89
Status: proposal LEXICAL passed Jan 89 X3J13
+ DECODE-UNIVERSAL-TIME-DAYLIGHT
Version 2, 30-Sep-88, Released 6 Oct 88
Status: Passed, Jan 89 x3j13
* DEFMACRO-LAMBDA-LIST
Version 2, 17-Mar-89
Status: ready for release?
+ DEFPACKAGE
Version 7, 2-Nov-88, Released 5 Dec 88
Comment: clarify "at variance" in editorial work?
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
Version 3, 8-Jan-89, Released 11-Jan-89
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-DEFAULT-VALUE-EVALUATION
Version 1, 5/13/88
Status: Passed, 1988
+ DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
Version 3, 7 Dec 88, Released 12-Dec-88
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-REDEFINITION
Synopsis: what happens if you redefine a DEFSTRUCT?
Version 3, 6-Feb-89
Status: Passed (as amended) Jan 89 X3J13
+ DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
Version 5, 12-Jan-89
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER
Version 1, 5/13/88
Status: Passed, 1988
+ DEFVAR-DOCUMENTATION
23-NOV-87, Version 2
Status: Passed, 1988?
+ DEFVAR-INIT-TIME
29-MAR-87, Version 2
Status: Passed, 1988?
+ DEFVAR-INITIALIZATION
Version 4 5-JUN-87
Status: Passed, 1988?
+ DESCRIBE-INTERACTIVE
Version 4, 15-Nov-88, Released 7-Dec-88
Synopsis: can DESCRIBE ask user a question?
Status: Proposal NO passed Jan 89 X3J13
! DESCRIBE-UNDERSPECIFIED
Version 1, 10-Mar-89, Released 16-Mar-89
Synopsis: making DESCRIBE generic was wrong; fix
status: ready for vote
!* DESTRUCTURING-BIND
Version 2, 25-Jan-89, Released 16-Mar-89
Synopsis: add DESTRUCTURING-BIND macro
Status: might need new version before vote
+ DISASSEMBLE-SIDE-EFFECT
Version 3 1/21/88
Status: Passed, 1988
+ DO-SYMBOLS-DUPLICATES
Version 3 23-NOV-87
Status: Passed, 1988?
+ DOTTED-MACRO-FORMS
Version 3, 15-Nov-88, Released 7-Dec-88
Status: passed, Jan 89 X3J13
+ DRIBBLE-TECHNIQUE
14-FEB-88, Version 2
Status: Passed, 1988?
! DYNAMIC-EXTENT
Version 3, 11-Jan-89, released 16-Mar-89
Comments: still some holes
Status: ready for vote?
+ EQUAL-STRUCTURE
Version 6, 11-Jan-89, Released 12-Jan-89
Status: Passed with amendments
Version 7, 15-Mar-89
Status: Passed Jan 89 X3J13 as amended.
* EQUALP-GENERIC
Version 1, 28-Feb-89
Synopsis: make EQUALP generic function
Comments: Various problems being worked on
Status: ** NEED NEW VERSION ***
* ERROR-CHECKING-IN-NUMBERS-CHAPTER
Version 1, 6-Mar-89
Synopsis: define 'should signal', 'might signal' for number fns
Status: ** NEED NEW VERSION **
! ERROR-NOT-HANDLED
Version 1, 25-Sep-88, Released 6-Oct-88 and 14-Mar-89
Status: ready for vote
+ EVAL-OTHER
8-JUN-88, Version 2
Status: Passed, 1988?
! EXIT-EXTENT
Version 6, 8-Jan-89, distributed at Jan89 X3J13
Rereleased 16-Mar-89
Status: tabled Jan89; ready for vote
+ EXPT-RATIO
Version 3, 31-Oct-88, Released 7 Dec 88
Status: passed, Jan 89 X3J13
+ FIXNUM-NON-PORTABLE
Version 4, 7-Dec-88, Released 12-Dec-88
Version 6, 17-Mar-89, as amended
Status: Passed, Jan 89 X3J13, as amended
+ FLET-DECLARATIONS
Version 2, 2 FEB 88
Status: Passed, 1988?
+ FLET-IMPLICIT-BLOCK
Version 6 5-JUN-87
Status: Passed, 1988?
+ FORMAT-ATSIGN-COLON
Version 4 5-JUN-87
Status: Passed, 1988?
+ FORMAT-COLON-UPARROW-SCOPE
Version 3, 5 FEB 88
Status: Passed, 1988?
+ FORMAT-COMMA-INTERVAL
Version 2, 15-JUN-87
Status: Passed, 1988?
+ FORMAT-E-EXPONENT-SIGN
Version 2, 2 Oct 88, Released 6 Oct 88
Status: Passed, Jan 89 X3J13
+ FORMAT-OP-C
11-JUN-87, Version 5
Status: Passed, 1988?
* FORMAT-PLURALS
Synopsis: remove ~P, add ~:@[singular~;plural~]
Status: no proposal
+ FORMAT-PRETTY-PRINT
Version 7, 15 Dec 88, Released 7 Dec 88
Comments: passed, Jan 89 X3j13
+ FUNCTION-CALL-EVALUATION-ORDER
Version 1, 22-MAR-88
Status: Passed, 1988
! FUNCTION-COERCE-TIME
Synopsis: When does SYMBOL-FUNCTION happen in MAPCAR?
Version 2, 16-sep-88, Released 8-Oct-88
Re-released: 16-Mar-89
Status: ready for vote?
+ FUNCTION-COMPOSITION
Synopsis: Add new functions
Version 5, 10-Feb-89
Status: Passed (as amended) Jan 89 X3J13
maybe this was passed as amendment to TEST-NOT-IF-NOT instead
+ FUNCTION-DEFINITION
Version 3, 10-Feb-89
Status: Passed (as amended) Jan 89 X3J13
! FUNCTION-NAME
Comment: renaming of SETF-FUNCTION-VS-MACRO, SETF-PLACES
SETF-FUNCTION-VS-MACRO
Version 3, 4-Nov-87, Released Nov 87
SETF-PLACES
Version 1, 11-Nov-88, Released 9-Dec-88
FUNCTION-NAME
Version 1, 27-Jan-89, Released 16-Mar-89
Status: ready for vote
+ FUNCTION-TYPE
Version 12, 4-SEP-88
Status: Passed, June 1988 X3J13, as amended
+ FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
Synopsis: Change semantics of argument types in function declarations
Version 3, 7-Dec-88, Released 12-Dec-88
Status: Passed, Jan 89 X3J13
+ FUNCTION-TYPE-KEY-NAME
Version 3, 13-FEB-88
Status: Passed, 1988
+ FUNCTION-TYPE-REST-LIST-ELEMENT
Version 5, 14-Nov-88, Released 8-Dec-88
Status: Passed, Jan 89 X3J13
! GENSYM-NAME-STICKINESS
Synopsis: no side effects if optional arg supplied
Version 1, 14-Feb-89, Released 14-Mar-89
Status: comments
Version 2, 16-Mar-89
Status: ready for release?
+ GET-MACRO-CHARACTER-READTABLE
Version 3, 11-Feb-89
Status: Passed (as amended) Jan 89 X3J13
+ GET-SETF-METHOD-ENVIRONMENT
Version 5 13-JUL-87
Status: Passed, 1988?
! HASH-TABLE-ACCESS
Synopsis: Add new accessors for hash-table properties
Version 1, 13-Sep-88 released 8-Oct-88
Version 2, 13 Oct 88, released 16-Mar-89
status: vote
+ HASH-TABLE-PACKAGE-GENERATORS
Version 7, 8-Dec-88, Released 9-Dec-88
Comments: The test-package-iterator example has the values
from the generator in the wrong order.
Status: passed, Jan 89 X3J13
* HASH-TABLE-PRINTED-REPRESENTATION
Version 2, 8-Jun-88
Comments: Use #S(ARRAY ...), #S(HASH-TABLE...), #S(PATHNAME...)?
Status: need new proposal
+ HASH-TABLE-TESTS
Version 2, 8-Dec-88, Released 8 Dec 8 8
Status: passed Jan 89 X3J13
+ IEEE-ATAN-BRANCH-CUT
Version 2, 11-Jan-89, Released 11-Jan-89
Status: passed, Jan 89 X3J13
* IGNORE-VARIABLE
Synopsis: default (IGNORE IGNORE)
Version 1, 6-Feb-89
+ IMPORT-SETF-SYMBOL-PACKAGE
Version 5 ??-MAY-87
Status: Passed, 1988?
! IN-PACKAGE-FUNCTIONALITY
Version 4, 12-Dec-88, Released 12-Dec-88
Status: tabled
Version 8, 15-Mar-89, Released 15-Mar-89
Status: ready for vote
+ KEYWORD-ARGUMENT-NAME-PACKAGE
8-NOV-87, Version 8
Status: Passed, 1988?
+ LAST-N
12-MAR-88, Version 2
Status: Passed, 1988?
+ LCM-NO-ARGUMENTS
Version 1, 17 Oct 88, Released 8 Dec 88
Status: passed, Jan 89 X3J13
! LISP-PACKAGE-NAME
Synopsis: change LISP to COMMON-LISP to avoid CLtL confusion
Version 1, 22 Dec 88, Released 11-Jan-89
Status: tabled; version 1 still ready for vote
! LISP-SYMBOL-REDEFINITION
Version 5, 22-Nov-88, Released 8 Dec 88
Comments: Don't like (DEFVAR CAR ...) example
14: Like simpler "Redefining any documented
definition on a symbol in the LISP package -- such as variables,
functions, constants, properties and property-lists, etc -- is
undefined, except for the explicitly allowed cases (e.g. dynamic
binding of variables)."
Status: tabled; version 5 still ready for vote
! LOAD-OBJECTS
Synopsis: Provide a way to allow defstruct/defclass objects in compiled files
Version 3, 9-Mar-89, released 16-Mar-89
Status: ready for vote?
! LOAD-TRUENAME
Synopsis: Make default pathname for LOAD inside LOAD same?
Version 1, 13-Mar-89, Released 16-Mar-89
Status: ready for vote
! LOCALLY-TOP-LEVEL
Version 2, 16-Mar-89, released 17-Mar-89
Status: ready to vote
! LOOP-AND-DISCREPANCY
Version 1, 15-Mar-89, released 16-Mar-89
status: ready for vote
+ MACRO-FUNCTION-ENVIRONMENT
Version 2, 8-JUN-88
Status: Passed, 1988
* MACRO-SPECIAL-FORMS
Synopsis: macros => implementation-dependent special forms doesn't work
Status: *** NEED PROPOSAL SUBMITTED ****
+ MAKE-PACKAGE-USE-DEFAULT
Version 2, 8 Oct 88, Released 12-Dec-88
Version 3, 16-Mar-89
Status: Passed, Jan 89 X3J13 as amended
! MAKE-STRING-FILL-POINTER
Synopsis: extend MAKE-STRING to take a fill-pointer?
Version 1, 20-Oct-88, released 16-Mar-89
Status: ready for vote
+ MAPPING-DESTRUCTIVE-INTERACTION
Version 2, 09-Jun-88, Released 8 Oct 88
Synopsis: [don't] define interaction of DELETE on MAPCAR'd list.
Status: passed, Jan 89 X3J13
+ NTH-VALUE
Version 4, 8-Dec-88, Released 8 Dec 88
Comment: amended to clarify when index out of range
Version 5, 17-Mar-89
Status: passed, as amended
+ PACKAGE-CLUTTER
Version 6, 12-Dec-88, Released 12-Dec-88
Comments: Accepted, with amendment
Version 7, 17-Mar-89
Status: Passed, Jan 89 X3J13, as amended
+ PACKAGE-DELETION
Version 5, 21 nov 88, Released 8 Dec 88
Comments: Minor glitches? Remove the description of "correctable" error to be signalled and
handled.
Status: passed, Jan 89 X3J13
!+ PACKAGE-FUNCTION-CONSISTENCY
Synopsis: allow strings for package arg everywhere uniformly
Version 2, 12-Jan-89, Released 12-Jan-89
Comment: Accepted MORE-PERMISSIVE with amendments
Version 3, 17-Mar-89, released 17-Mar-89
Status: vote to accept wording as intent of amendment
* PATHNAME-CANONICAL-TYPE
Synopsis: allow canonical :SOURCE-LISP to MAKE-PATHNAME;
require PATHNAME-TYPE to return same?
Version 1, 07-Jul-88
Comments: only add the :TYPE :SOURCE-LISP, not PATHNAME-CANONICAL-TYPE?
Status: => "pathname" committee?
* PATHNAME-LOGICAL
Synopsis: add logical pathnames (pathnames for an imaginary portable
file system, which get translated by site-dependent translations into
physical pathnames on an actual file system)
Status: no proposal yet
* PATHNAME-PRINT-READ
Synopsis: Print pathnames like #P"asdf"?
Version 1, 21-Oct-88
Comments: Numerous, pro, con. Print like #S(pathname ...)?
Status: *** NEED NEW VERSION ***
+ PATHNAME-STREAM
Version 6 14-NOV-87
Status: Passed, 1988?
+ PATHNAME-SYMBOL
Version 5 5-FEB-88
Status: Passed, 1988?
* PATHNAME-SUBDIRECTORY-LIST
Synopsis: How to deal with subdirectory structures in pathname functions
Version 3, 29-Dec-88
Comments: typos and proposed simplifications
Status: *** NEED NEW VERSION ***
* PATHNAME-SYNTAX-ERROR-TIME
Synopsis: when are errors in pathnames detected?
Version 1, 7-Jul-88
Comments: various
Status: need new version? ==> ERRORS-IN-FILE-CHAPTERS?
+ PATHNAME-UNSPECIFIC-COMPONENT
Synopsis: More extensions to :UNSPECIFIC
Version 1, 29-Dec-88, Released 12-Jan-89
Version 2, 17-Mar-89
Status: Passed, Jan 89 X3j13, as amended
+ PEEK-CHAR-READ-CHAR-ECHO
Version 3, 8-Oct-88, Released 8 Oct 88
Synopsis: PEEK-CHAR, READ-CHAR on streams made by MAKE-ECHO-STREAM
Status: Passed, Jan 89 X3J13
* PRETTY-PRINT-INTERFACE
Version 3, 15-Mar-89
Synopsis: standardize interface to prettyprinter
Status: Need new version
+ PRINC-CHARACTER
29-APR-87, Version 2
Status: Passed, 1988?
* PRINT-CIRCLE-SHARED
Synopsis: does *PRINT-CIRCLE* cause shared structure to print with #=?
Status: Not submitted yet ** NEED WRITEUP **
+ PRINT-CIRCLE-STRUCTURE
Version 3, 20 Sep 88, Released 8 Oct 88
Comments: Accepted, with amendment
Version 4, 17-Mar-89
Status: Passed, Jan 89 X3J13, as amended
! PROCLAIM-LEXICAL
Version 9, 8-Dec-88, Released 12-Dec-88
Synopsis: add LEXICAL proclaimation
Comments: lengthy mail; amendments at Jan meeting
Status: tabled, vote on version 9 (w/o amendments)
+ PUSH-EVALUATION-ORDER
Version 5, 25-NOV-87
Status: Passed, 1988?
+ RANGE-OF-COUNT-KEYWORDS
Version 3, 9-Oct-88, Released 14-Oct-88
Status: passed, Jan 89 X3J13
+ RANGE-OF-START-AND-END-PARAMETERS
Version 1, 14-Sep-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
* READ-CASE-SENSITIVITY
Synopsis: Allow readtables to be case sensitive
Comments: use function or keyword?
Status: need new version
* READ-DELIMITED-LIST-EOF
Synopsis: eof in read deliminted list signals an error
Status: awaiting submission
! REAL-NUMBER-TYPE
Synopsis: add REAL = (OR RATIONAL FLOAT) & range
Version 3, 13-Jan-89, released 16-Mar-89
Status: vote?
+ REDUCE-ARGUMENT-EXTRACTION
Version 3 13-FEB-88
Status: Passed, 1988?
!* REMF-DESTRUCTION-UNSPECIFIED
Synopsis: Specification of side-effect behavior in CL
Version 4, 29-Nov-88, Released 12-Jan-89
Status: straw vote in favor of this, BarMar will make amendments
Version 5, 15-Mar-89
Comment: needs a little work
Status: *** NEARLY READY -- NEED NEW VERSION ****
+ REQUIRE-PATHNAME-DEFAULTS
Version 6, 9 Dec 88, Released 09 Dec 88
Status: passed, Jan 89 X3j13
+ REST-LIST-ALLOCATION
Version 3, 12-Dec-88, Released 12-Dec-88
Status: proposal MAY-SHARE passed, Jan 89 X3J13
+ RETURN-VALUES-UNSPECIFIED
Version 6, 9 Dec 88, Released 9-Dec-88
Status: passed, Jan 89 X3J13
+ ROOM-DEFAULT-ARGUMENT
Version 1, 12-Sep-88, Released 8 Oct 88
Status: passed, Jan 89 X3J13
* SETF-MULTIPLE-STORE-VARIABLES
Synopsis: Allow multiple "places" in SETF stores
Version 1, 5-Dec-88
Status: *** NEED NEW VERSION ****
+ SETF-SUB-METHODS
Version 5, 12-Feb-88, Released 8 Oct 88
Synopsis: careful definition of order inside (SETF (GETF ...) ...)
Status: passed, Jan 89 X3J13
+ SHADOW-ALREADY-PRESENT
Version 4 10-NOV-87
Status: Passed, 1988?
+ SHARPSIGN-PLUS-MINUS-PACKAGE
Version 3 14-NOV-87
Status: Passed, 1988?
+ SPECIAL-TYPE-SHADOWING
Synopsis: intersection of types when proclaimed special has local type
declaration
Version 1, 4-Nov-88, released 11-Jan-89
Status: passed, Jan 89 X3J13
+ STANDARD-INPUT-INITIAL-BINDING
Version 8, 8 Jul 88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
+ STEP-ENVIRONMENT
Version 3, 20-Jun-88, Released 7 Oct 88
Version 4, 17-Mar-89
status: Passed, Jan 89 X3J13, as amended
+ STREAM-ACCESS
Version 2, 30-Nov-88, Released 9 Dec 88
Status: ADD-TYPES-ACCESSORS passed, Jan 89 X3J13
+ SUBSEQ-OUT-OF-BOUNDS
29-MAR-88 Version 2
Status: Passed, 1988?
* SUBTYPEP-ENVIRONMENT
Version 1, 2-Jan-89
Status: ** missing writeup ***
+ SUBTYPEP-TOO-VAGUE
Version 4, 7-Oct-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
+ SYMBOL-MACROLET-DECLARE
Version 2, 9-Dec-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13
!+ SYMBOL-MACROLET-SEMANTICS
Version 5, 30-Nov-88, Released 9 Dec 88
Status: Passed, Jan 89 X3J13
Version 6, 14-Mar-89, released 16-Mar-89
Status: ready for vote
+ TAILP-NIL
Version 5, 9-Dec-88, Released 12-Dec-88
Synopsis: Operation of TAILP given NIL
Status: passed, Jan 89 X3J13
+ TEST-NOT-IF-NOT
Version 3, 1 Dec 88, Released 9 dec
Version 4, 18-Mar-89
Status: Need new version as amended.
! THE-AMBIGUITY
Version 2, 11-Jan-89, Released 11-Jan-89
Comments: typo, sense wrong
Status: tabled, vote on 2
! TIME-ZONE-NON-INTEGER
Version 1, 13-Mar-89, Released 16-Mar-89
Status: ready for vote
+* TYPE-OF-UNDERCONSTRAINED
Version 3, 12-Dec-88, Released 12 Dec 88
Comments: Accepted, with amendments
Version 5, 16-Mar-89
Comments: constraints wrong
Status: ** NEED NEW VERSION ***
! UNDEFINED-VARIABLES-AND-FUNCTIONS
Synopsis: What happens on an undefined function call, unbound variable ref?
Version 1, 29-Nov-88, Released 11-Jan-89
Comments: Lumping SLOT-UNBOUND in with unbound special variables was a mistake,
as SLOT-UNBOUND is an extension mechanism, not only a safety checking
mechanism. Also there were some wording problems. Gabriel and Gregor
are to submit a revised proposal.
No version arrived.
Status: vote on 1?
+ UNREAD-CHAR-AFTER-PEEK-CHAR
Version 2, 2-Dec-88, Released 12-Dec-88
Status: passed, Jan 89 X3J13
+ VARIABLE-LIST-ASYMMETRY
Version 3, 08-Oct-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13
+ WITH-OUTPUT-TO-STRING-APPEND-STYLE
Version 5, 7-JUN-88
Status: Passed, 1988?
∂19-Mar-89 2015 @Score.Stanford.EDU:jle@Orange.stanford.edu CS Colloquium Reminder
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Mar 89 20:15:36 PST
Received: from Orange.stanford.edu by SCORE.STANFORD.EDU with TCP; Sun 19 Mar 89 20:06:02-PST
Received: by Orange.stanford.edu (5.59/25-eef) id AA08920; Thu, 9 Mar 89 14:40:48 PDT
Date: Thu, 9 Mar 89 14:40:48 PDT
From: Jeffrey Eppinger <jle@Orange.stanford.edu>
Message-Id: <8903092240.AA08920@Orange.stanford.edu>
To: csl-everyone@sierra, faculty@score, students@score
Subject: CS Colloquium Reminder
The Computer Productivity Paradox
Michael L. Dertouzos
Professor and Director
MIT Laboratory for Computer Science
Computer Science Colloquium
Tuesday, March 14, 1989, 4:15pm
Jordan Hall (Building 420), Room 040
Stanford University
=> Refreshments will be served at 3:45pm outside the Lecture Hall <=
Abstract
The first half century of the computer field has been largely supply side
driven by a wondrous new technology that is still evolving and continues
to fuel our imagination. One side of the paradox lies in the apparent
lack of aggregate effect (either up or down) of computers on conventional
measures of human productivity. The other side of the paradox lies in the
indifference of makers and users of computer hardware and software about
the effect of such systems upon human productivity. The talk will examine
how computers might help current productivity weaknesses especially of the
white collar kind, how they might open new productive endeavors, how they
should not be misused and how information might be valued so that we can
develop effective measures of information-processing productivity. The
mission ahead is historic--to apply computer science and information
technology across the world's entire economic front so as to increase
human productivity. The associated question is equally ominous:
Can it be done?
∂19-Mar-89 2358 @Score.Stanford.EDU:jcm@ra.stanford.edu Info on Concept 100?
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Mar 89 23:58:13 PST
Received: from ra.stanford.edu by SCORE.STANFORD.EDU with TCP; Sun 19 Mar 89 23:52:40-PST
Received: by ra.stanford.edu (5.59/25-eef) id AA01568; Sun, 19 Mar 89 21:58:26 PDT
Date: Sun, 19 Mar 89 21:58:26 PDT
From: John Mitchell <jcm@ra.stanford.edu>
Message-Id: <8903200558.AA01568@ra.stanford.edu>
To: csd@score, faculty@score, su-etc@score
Subject: Info on Concept 100?
I have been using a Concept 100without
a manual. This has not been a problem until tonight,
when I inadvertantly turned my modem on
while someone else was talking on the phone.
By luck, the tone of the conversation switched
my terminal into 300 baud, half-duplex, which I am
unable to switch out of
((not having terminal documentation). Any suggestions besides
the obvious (throw it away) would be appreciated.
Thnaks.
∂19-Mar-89 2358 @Score.Stanford.EDU:jcm@ra.stanford.edu Info on Concept 100?
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 19 Mar 89 23:58:13 PST
Received: from ra.stanford.edu by SCORE.STANFORD.EDU with TCP; Sun 19 Mar 89 23:52:40-PST
Received: by ra.stanford.edu (5.59/25-eef) id AA01568; Sun, 19 Mar 89 21:58:26 PDT
Date: Sun, 19 Mar 89 21:58:26 PDT
From: John Mitchell <jcm@ra.stanford.edu>
Message-Id: <8903200558.AA01568@ra.stanford.edu>
To: csd@score, faculty@score, su-etc@score
Subject: Info on Concept 100?
I have been using a Concept 100without
a manual. This has not been a problem until tonight,
when I inadvertantly turned my modem on
while someone else was talking on the phone.
By luck, the tone of the conversation switched
my terminal into 300 baud, half-duplex, which I am
unable to switch out of
((not having terminal documentation). Any suggestions besides
the obvious (throw it away) would be appreciated.
Thnaks.
∂20-Mar-89 0002 X3J13-mailer X3J13 mailer
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 20 Mar 89 00:02:29 PST
Received: from relay2.cs.net by RELAY.CS.NET id aa07578; 20 Mar 89 2:47 EST
Received: from utokyo-relay by RELAY.CS.NET id ai28052; 20 Mar 89 2:38 EST
Received: by ccut.cc.u-tokyo.junet (5.51/6.3Junet-1.0/CSNET-JUNET)
id AA05005; Mon, 20 Mar 89 14:16:29 JST
Received: from kepa.cc.aoyama.junet by aoyama.cc.aoyama.junet (4.0/6.4J.BETA2-agu2)
id AA08005; Mon, 20 Mar 89 13:59:10 JST
Received: by kepa.cc.aoyama.junet (4.0/6.3Junet-1.0)
id AA00673; Mon, 20 Mar 89 13:59:37 JST
Date: Mon, 20 Mar 89 13:59:37 JST
From: Masayuki Ida <ida%cc.aoyama.junet@UTOKYO-RELAY.CSNET>
Return-Path: <ida@cc.aoyama.junet>
Message-Id: <8903200459.AA00673@kepa.cc.aoyama.junet>
To: x3j13@SAIL.STANFORD.EDU
Cc: ida%cc.aoyama.junet@UTOKYO-RELAY.CSNET
Subject: X3J13 mailer
I finally found that I did NOT receive ANY X3J13 mails
since March 6 or 7 until today.
I believe something was wrong with the mailer at stanford or
at the japanese gate way.
Editorial mailer, and other mailers are OK.
Anyway, I will attend the Fairfax meeting as a member,
though I have not get any fresh information for two weeks.
Looking forward to seeing you all at Fairfax.
Masayuki Ida
∂20-Mar-89 0942 @Score.Stanford.EDU:janelin@krakatoa.stanford.edu Seminar by Robotics Faculty Candidate
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Mar 89 09:42:09 PST
Received: from krakatoa.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 20 Mar 89 09:30:04-PST
Received: by krakatoa.stanford.edu; Mon, 20 Mar 89 09:26:51 PST
Date: 20 Mar 1989 0926-PST (Monday)
From: Jane Lintott <janelin@krakatoa.stanford.edu>
Return-Path: <jutta@coyote.stanford.edu>
Received: from Sierra.Stanford.EDU by krakatoa.stanford.edu with TCP; Fri, 17 Mar 89 15:01:20 PST
Received: from coyote.stanford.edu by sierra.STANFORD.EDU (3.2/4.7); Fri, 17 Mar 89 15:03:17 PST
Received: by coyote.stanford.edu; Fri, 17 Mar 89 15:09:29 PST
Date: 17 Mar 1989 1509-PST (Friday)
From: Jutta McCormick <jutta@coyote.stanford.edu>
To: cedar@coyote.stanford.edu, faculty@score.stanford.edu,
davis@score.stanford.edu, cannon@sierra.stanford.edu,
bxr@sail.stanford.edu, myers@polya.stanford.edu
Cc:
Subject: Seminar by Robotics Faculty Candidate
SPECIAL ROBOTICS SEMINAR
Speaker: Michael Erdmann
M.I.T.
Title: MOTION PLANNING WITH UNCERTAINTY: A PROBABILISTIC APPROACH
Date: Monday, March 20, 1989
Time: 4:00 p.m.
Place: Cedar Hall Conference Room
ABSTRACT
Robots must successfully solve tasks in the presence of uncertainty.
Uncertainty arises from errors in sensing, modelling, and control. In
the past much work has been directed towards finding strategies that
are guaranteed to succeed in a specific number of steps. This talk
presents an alternative approach: The purposeful injection of randomized
actions in a strategy. Randomized actions are useful in a variety of
settings. For instance, a random motion can make progress even when
sensory information is inadequate to decide on the next proper course
of action. In some settings a randomized action may be preferable to an
action that is guaranteed to be successful but that requires too much
computational effort or execution time.
In this talk I will present a few examples involving randomized
actions. I will mention implementations of the theory, both in
simulation and on a physical manipulator. I will also discuss the
relationship of randomized strategies to the pre-image framework
developed by Lozano-Perez, Mason, and Taylor for generating guaranteed
strategies.
∂20-Mar-89 0959 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Good News
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Mar 89 09:59:30 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 20 Mar 89 09:58:44-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA05381; Mon, 20 Mar 89 08:51:50 -0800
Date: Mon, 20 Mar 1989 8:51:48 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: ac@score
Subject: Good News
Message-Id: <CMM.0.87.606415908.chandler@polya.stanford.edu>
The faculty meeting scheduled for tomorrow has been canceled.
∂20-Mar-89 1008 @Score.Stanford.EDU:chandler@polya.Stanford.EDU Last Faculty Lunch - Winter Quarter
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Mar 89 10:08:06 PST
Received: from polya.Stanford.EDU by SCORE.STANFORD.EDU with TCP; Mon 20 Mar 89 10:05:22-PST
Received: by polya.Stanford.EDU (5.61/25-eef) id AA10129; Mon, 20 Mar 89 10:05:22 -0800
Date: Mon, 20 Mar 1989 10:05:16 PST
From: "Joyce R. Chandler" <chandler@polya.stanford.edu>
To: faculty@score, bureaucrats@score
Cc: staff-rep@score
Subject: Last Faculty Lunch - Winter Quarter
Message-Id: <CMM.0.87.606420316.chandler@polya.stanford.edu>
Come to the last faculty lunch of the Winter quarter - tomorrow 3-21 at 12:15
in MJH-146. There's no formal agenda....no invited guest. Just come and enjoy!
∂20-Mar-89 1229 X3J13-mailer Re: Fatal vesus Harmless
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 20 Mar 89 12:29:29 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
id AA03785; Mon, 20 Mar 89 12:01:45 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.1)
id AA18569; Mon, 20 Mar 89 11:57:53 PST
Received: by clam.sun.com (4.0/SMI-4.0)
id AA02722; Mon, 20 Mar 89 12:01:32 PST
Date: Mon, 20 Mar 89 12:01:32 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903202001.AA02722@clam.sun.com>
To: RPG@SAIL.Stanford.EDU, x3j13@SAIL.Stanford.EDU
Subject: Re: Fatal vesus Harmless
Cc: cl-editorial@SAIL.Stanford.EDU
Dick Gabriel's discussion of fatal versus harmless made sense
to me. I'm going to propose here that within that framework
it can make sense to PERMIT certain SPECIFIED side effects.
I still say that "unspecified by harmless" loses.
To paraphrase, a program P "has fatal consequences"
exactly if it can be preceded and followed by conforming code
so that the entire sequence including P may "crash or abnormally
terminate".
The key question remaining in my mind is what side effects
can be considered harmless. Dick mentioned a property-list-like
data structure. Let's talk about hash tables and MAPHASH.
Specifically let's talk about the result of
(let ((result (list)))
(maphash #'(lambda (key value) (push (list key value) result))
table)
result)
The order of the result of this expression is unspecified for a
given hash table at a given time, but the set of key-value pairs
is specified.
Is it OK for CONS to cause the order of this list to change? Is it
OK for CAR to cause it to change?
Since we are trying to discuss harmless side effects, suppose we wish
to allow GC to rehash, possibly changing the order. The answer must
be that CONS can change the list, because it may invoke the GC.
Since we don't specify what operations can allocate storage, it
appears that we will prefer to say that any operation at all
is permitted to change the value of the example expression above.
In either case, we have no "unspecified but harmless" side
effect of some particular Common Lisp operation. We have a
particular class of side effects that are PERMITTED
in certain circumstances. We may choose to specify that
certain classes of side effects are ALWAYS permitted.
We may say that certain side effects are permitted -- to certain
operations. Suppose we wish to permit certain Common Lisp operations
to issue progress messages, but *not* to consider progress messages as
side effects permitted for all Common Lisp operations. In
that case it appears to me that we specify that certain operations may
issue progress messages.
While agreeing with Dick Gabriel's recent note, nowhere do I see
the concept "unspecified by harmless" as useful to the definition
of Common Lisp. Some side effects may be PERMITTED. Some may even
be permitted to ALL COMMON LISP OPERATIONS. These are specified
effects, not unspecified effects, and "permitted" I think conveys
the concept much more clearly than "harmless".
∂20-Mar-89 1246 @Score.Stanford.EDU:jle@Orange.stanford.edu Mailer Error
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 20 Mar 89 12:46:32 PST
Received: from Orange.stanford.edu by SCORE.STANFORD.EDU with TCP; Mon 20 Mar 89 11:37:38-PST
Received: by Orange.stanford.edu (5.59/25-eef) id AA00899; Mon, 20 Mar 89 11:37:13 PDT
Date: Mon, 20 Mar 89 11:37:13 PDT
From: Jeffrey Eppinger <jle@Orange.stanford.edu>
Message-Id: <8903201937.AA00899@Orange.stanford.edu>
To: csl-everyone@sierra, faculty@score, students@score
Subject: Mailer Error
If you received reminder mail about this colloquium this morning...
don't be fooled. It's a mailer error. The colloquium was last week.
I'm sorry you may not have received your reminder.
Jeff.
∂20-Mar-89 1315 CL-Compiler-mailer issue COMPILER-VERBOSITY, version 6
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 20 Mar 89 13:15:01 PST
Received: from maths.bath.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa07991; 20 Mar 89 18:58 GMT
Received: from xenakis by mordell.maths.bath.AC.UK id aa19210;
20 Mar 89 18:59 GMT
To: masinter.pa@xerox.com
CC: cl-compiler@sail.stanford.edu, x3J13@sail.stanford.edu
In-reply-to: masinter.pa@com.xerox's message of 16 Mar 89 05:47 PST <890316-054837-3596@Xerox>
Subject: issue COMPILER-VERBOSITY, version 6
Date: Mon, 20 Mar 89 19:02:07 GMT
From: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
Sender: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
b
∂21-Mar-89 0847 debra@russell.Stanford.EDU REMINDER-EVENING SEMINAR
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Mar 89 08:47:41 PST
Received: from localhost by russell.Stanford.EDU (4.0/inc-1.0)
id AA04102; Tue, 21 Mar 89 08:51:21 PST
Message-Id: <8903211651.AA04102@russell.Stanford.EDU>
To: evesem@russell.Stanford.EDU
Cc: debra@russell.Stanford.EDU, kuder@russell.Stanford.EDU
Subject: REMINDER-EVENING SEMINAR
Date: Tue, 21 Mar 89 08:51:20 PST
From: Debra Alty <debra@russell.Stanford.EDU>
REMINDER
The next EVENING SEMINAR will be Wednesday, March 8th @ 7:30pm in the
CSLI Cordura Conference Room.
Professor Amos Tversky, Psychology Department, will be leading the
discussion.
The following will be served:
Teriyaki chicken sticks Saki
Sushi Plum Wine
Veggies w/dip Beer
Fortune cookies Sparkling waters
Coffee
Tea
Debra
∂21-Mar-89 1106 debra@russell.Stanford.EDU C O R R E C T I O N - REMINDER-EVENING SEMINAR
Received: from russell.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Mar 89 11:06:36 PST
Received: from [127.0.0.1] by russell.Stanford.EDU (4.0/inc-1.0)
id AA04678; Tue, 21 Mar 89 09:02:54 PST
Message-Id: <8903211702.AA04678@russell.Stanford.EDU>
To: evesem@russell.Stanford.EDU
Cc: debra@russell.Stanford.EDU, kuder@russell.Stanford.EDU
Subject: C O R R E C T I O N - REMINDER-EVENING SEMINAR
Date: Tue, 21 Mar 89 09:01:22 PST
From: Debra Alty <debra@russell.Stanford.EDU>
C O R R E C T I O N
REMINDER
The next EVENING SEMINAR will be Wednesday, March 22nd @ 7:30pm in the
CSLI Cordura Conference Room.
Professor Amos Tversky, Psychology Department, will be leading the
discussion.
The following will be served:
Teriyaki chicken sticks Saki
Sushi Plum Wine
Veggies w/dip Beer
Fortune cookies Sparkling waters
Coffee
Tea
Debra
∂21-Mar-89 1453 X3J13-mailer Issue: PATHNAME-COMPONENT-VALUE (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Mar 89 14:53:02 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 562306; Tue 21-Mar-89 17:52:49 EST
Date: Tue, 21 Mar 89 17:52 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-COMPONENT-VALUE (version 1)
To: X3J13@SAIL.STANFORD.EDU
References: <19890320180405.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890321225242.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
This issue came up while reviewing section 2.2 of the draft standard.
Issue: PATHNAME-COMPONENT-VALUE
Related Issues:PATHNAME-CANONICAL-TYPE,
PATHNAME-SUBDIRECTORY-LIST,
PATHNAME-UNSPECIFIC-COMPONENT,
PATHNAME-WILD
References: CLtL pp.410-3
Category: CLARIFICATION and CHANGE
Edit history: Version 1, 20-Mar-89, by Moon
Problem description:
CLtL is overly restrictive on the possible values for pathname components.
These restrictions are described in a funny way that makes it unclear
whether they are requirements, guidelines, or just an example.
The restrictions are not all written down in one place, but they appear
to be as follows:
Host nil, :wild, string, or list of strings
Device nil, :wild, string, or something else ("structured")
Directory nil, :wild, string, or something else ("structured")
Name nil, :wild, string, or something else ("structured")
Type nil, :wild, or string
Version nil, :wild, :newest, positive integer, implementation
dependent symbol, or implementation-dependent integer
less than or equal to zero. Suggestions include :oldest,
:previous, :installed, 0, and -1.
PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN allowed implementations to
allow any component to be :UNSPECIFIC. This has been voted in.
PATHNAME-SUBDIRECTORY-LIST proposes a list of strings and keyword
symbols for the directory component.
PATHNAME-CANONICAL-TYPE proposes some new operations but does not
change the possible values of the type component.
PATHNAME-WILD proposes a portable way to test for implementation
dependent component values that indicate wildcard matching. It
does not change the possible values of any component.
Proposal (PATHNAME-COMPONENT-VALUE:SPECIFY):
The points of the proposal have been numbered to facilitate
amendments to remove or modify individual points.
When examining pathname components, conforming programs must be
prepared to encounter any of the following values:
1. Any component can be NIL, which means the component has not
been specified.
2. Any component can be :UNSPECIFIC, which means the component has
no meaning in this particular pathname.
3. Any component can be :WILD, which matches any component value.
Wild pathnames can be used with DIRECTORY but not with OPEN.
4. The host, device, directory, name, and type can be strings.
5. The host and device can be a list, a structure, or a
standard-object at the discretion of the implementation.
6. The directory can be a list of strings and symbols as detailed in
PATHNAME-SUBDIRECTORY-LIST (this assumes that it passes.)
7. The version can be any symbol or any integer. The symbol :NEWEST
refers to the largest version number that already exists in the file
system when reading, overwriting, appending, superseding, or directory
listing an existing file, and refers to the smallest version number
greater than any existing version number when creating a new file.
When constructing a pathname from components, conforming programs
must follow these rules:
11. Any component can be NIL. NIL in the host may mean a default host
rather than an actual NIL in some implementations.
12. Any component can be :WILD, which matches any component value.
Wild pathnames can be used with DIRECTORY but not with OPEN.
13. The host, device, directory, name, and type can be strings.
14. The directory can be a list of strings and symbols as detailed in
PATHNAME-SUBDIRECTORY-LIST (this assumes that it passes.)
15. The version can be :NEWEST.
16. Any component can be taken from the corresponding component
of another pathname on the same host and device.
17. An implementation might support other values for some
components, but a portable program cannot use those values.
An implementation might allow values to be transferred between
pathnames on different hosts or different devices, but a portable
program cannot rely on that.
A conforming program can use implementation-dependent values
but this can make it non-portable, for example, it might work
only with Unix file systems.
18. It is suggested, but not required, that implementations use
positive integers starting at 1 as version numbers, recognize
the symbol :oldest to designate the smallest existing version
number, and use keyword symbols for other special versions.
Consequences:
The changes relative to CLtL plus PATHNAME-UNSPECIFIC-COMPONENT
are as follows:
The definition of "structured" component is restricted to lists,
structures, and standard-objects, rather than allowing any object
whatsoever.
"Structured" hosts are allowed, a generalization of CLtL's list
of strings.
"Structured" directories are replaced by PATHNAME-SUBDIRECTORY-LIST.
"Structured" names are forbidden.
The difference between what component values a program can depend
on being able to use, versus what component values a program must
be prepared to encounter, is clarified.
Rationale:
This should make it easier to write portable programs that deal with
pathnames and make it easier for implementors by clarifying the
framework into which they must fit. Also it should make it easier
to write the Common Lisp language specification by resolving some
things that were unclear about the status quo.
Adding "structured" hosts conforms to current practice.
Substituting a default host for NIL conforms to current practice
in implementations that require all pathnames to have a specific host.
Removing "structured" names should improve portability without causing
any harm, assuming no implementation uses structured names. This will
improve portability by allowing programs to do string manipulation on
names, although such programs still have to be careful since the valid
characters and maximum length of a name are implementation-dependent.
Disallowing transferral of nonstandard component values between
different hosts or different devices allows implementations to support
multiple incompatible file systems.
Current practice:
All versions of Symbolics Genera violate CLtL in the matter of hosts,
since it uses standard-objects as the host component. Genera deviates
slightly from PATHNAME-SUBDIRECTORY-LIST, but otherwise conforms to
PATHNAME-COMPONENT-VALUE:SPECIFY.
Other implementations were not surveyed.
This proposal assumes that no current or planned implementation
uses structured names, not even for wildcards.
Cost to Implementors:
Most implementations already conform, except for the changes required
by PATHNAME-UNSPECIFIC-COMPONENT and PATHNAME-SUBDIRECTORY-LIST, so
the cost of this proposal itself should be minimal. It is conceivable
that an implementation may exist that has to change its pathname
representation, for example one that uses numbers as structured devices.
Cost to Users:
None.
Cost of non-adoption:
Pathnames will continue to be a poorly specified part of the language.
Performance impact:
None of any significance.
Benefits/Esthetics:
The boundary between the specified behavior of pathnames and the
implementation-dependent behavior of pathnames will be more clear.
Discussion:
A possible alternative to item 16 that's worth considering is:
16. Any component can be taken from the corresponding component
of another pathname. When the two pathnames are for incompatible
file systems (in implementations that support multiple file
systems), an appropriate translation occurs. If no meaningful
translation is possible, an error is signalled. The definition
of "appropriate" and "meaningful" is implementation-dependent.
This provides more useful behavior that conforming programs can
depend upon, but the behavior cannot be as precisely specified.
A significant amount of the Symbolics Genera pathname facility is
related to this capability, and it's used a lot in heterogeneous
networks, so maybe this is a useful capability that ought to be
called for in the language. The cost to implementors is small since
they could define "appropriate" and "meaningful" to be whatever is
easiest for them, if their users don't complain.
∂21-Mar-89 1455 X3J13-mailer Issue: COMMON-TYPE (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Mar 89 14:55:40 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 562312; Tue 21-Mar-89 17:55:26 EST
Date: Tue, 21 Mar 89 17:55 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COMMON-TYPE (version 1)
To: X3J13@SAIL.STANFORD.EDU
References: <19890320162410.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890321225520.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
This issue came up while reviewing section 2.2 of the draft standard.
Issue: COMMON-TYPE
References: CLtL p.35, p.76
Category: CHANGE
Edit history: Version 1, 20-Mar-89, by Moon
Problem description:
The type COMMON is defined in a very peculiar way and does not seem to
be useful for anything. It can be extended by users using DEFSTRUCT,
but not DEFTYPE nor DEFCLASS, but it cannot be extended by implementations.
Whether certain types such as NUMBER and ARRAY are subtypes of COMMON
is implementation-dependent. The goal of having the COMMON type was
probably to improve portability, but it is unclear how it could actually
be used in that way.
Proposal (COMMON-TYPE:REMOVE):
Remove COMMON and COMMONP from the language.
Rationale:
Keeping the definition of COMMON accurate in the new specification, in
the face of changes elsewhere in the language such as the introduction
of CLOS and the possible introduction of character registries, is
difficult when no one is sure what COMMON is for. If no one uses COMMON,
it would be less work to just get rid of it.
Current practice:
Every implementation probably implements COMMON. Moon has never seen it
used except in a program to test whether its implementation matched CLtL.
Cost to Implementors:
None.
Cost to Users:
None unless they are actually using COMMON.
Cost of non-adoption:
Implementors would have to maintain COMMON. Users would have to try to
understand it, or figure out that they didn't care about it.
Performance impact:
None.
Benefits:
Simpler language.
Esthetics:
Simpler language.
Discussion:
None.
∂21-Mar-89 1458 X3J13-mailer Issue: COMPLEX-RATIONAL-RESULT (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Mar 89 14:58:19 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 562314; Tue 21-Mar-89 17:58:03 EST
Date: Tue, 21 Mar 89 17:57 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COMPLEX-RATIONAL-RESULT (version 1)
To: X3J13@SAIL.STANFORD.EDU
References: <19890320164136.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890321225757.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
This issue came up while reviewing section 2.2 of the draft standard.
Issue: COMPLEX-RATIONAL-RESULT
References: CLtL p.203
Category: CLARIFICATION
Edit history: Version 1, 20-Mar-89, by Moon
Problem description:
Referring to irrational and transcendental functions, CLtL says:
When the arguments to a function in this section are all rational and
the true mathematical result is also (mathematically) rational, then
unless otherwise noted an implementation is free to return either an
accurate result of type rational or a single-precision floating-point
approximation. If the arguments are all rational but the result cannot
be expressed as a rational number, then a single-precision
floating-point approximation is always returned.
Referring to EXPT, CLtL says:
If the base-number is of type RATIONAL and the power-number is an
INTEGER, the calculation will be exact and the result will be of
type RATIONAL; otherwise a floating-point approximation may result.
What about arguments of type (complex rational)?
Proposal (COMPLEX-RATIONAL-RESULT:EXTEND):
Extend the paragraph quoted above to cover the components of complex
numbers. For (complex rational) arguments, a mathematically rational
result can be rational, (complex rational), or (complex float) at the
discretion of the implementation. For EXPT of a (complex rational) to
an integer power, the calculation must be exact and the result will
be rational or (complex rational).
Examples:
(log #c(-16 16) #c(2 2)) => 3 or approximately #c(3.0 0.0)
(expt #c(2 2) 3) => #c(-16 16)
(expt #c(2 2) 4) => -64
Rationale:
This seems most consistent with the treatment of real numbers.
Current practice:
Symbolics Genera 7.4 returns a (complex float) for the first example
and returns the specified answers for the second and third examples.
Other implementations were not surveyed.
Cost to Implementors:
Only EXPT would have to change, since the type of the other results
is at the discretion of the implementation.
Cost to Users:
Probably none, but it is hard to predict.
Cost of non-adoption:
Slightly less self-consistent language.
Performance impact:
None of any significance.
Benefits/Esthetics:
More self-consistent language.
Discussion:
None.
∂21-Mar-89 1500 X3J13-mailer Issue: HASH-TABLE-SIZE (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Mar 89 15:00:44 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 562317; Tue 21-Mar-89 18:00:29 EST
Date: Tue, 21 Mar 89 18:00 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-SIZE (version 1)
To: X3J13@SAIL.STANFORD.EDU
References: <19890320165503.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890321230023.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
This issue came up while reviewing section 2.2 of the draft standard.
Issue: HASH-TABLE-SIZE
References: CLtL p.283
Category: CLARIFICATION
Edit history: Version 1, 20-Mar-89, by Moon
Problem description:
CLtL contradicts itself on the meaning of the :SIZE argument to
MAKE-HASH-TABLE. At the top of p.283, it says that the size is "the
maximum number of entries it can hold. Usually the actual capacity of
the table is somewhat less." At the bottom of the page it says "this
argument serves as a hint to the implementation of approximately how
many entries you intend to store." So does the :SIZE intended to be the
actual capacity of the table, or the amount of storage allocated to hold
the table. For example, if the implementation of hash tables is
designed for a loading of 65%, and the user specifies :SIZE 100, does
the table returned have space allocated for 100 entries, so that it
overflows and becomes bigger when 65 entries are inserted, or does the
table have space allocated for 154 entries, so that it overflows and
becomes bigger when 100 entries are inserted?
Proposal (HASH-TABLE-SIZE:INTENDED-ENTRIES):
Believe the bottom of p.283 rather than the top. The :SIZE argument
is approximately the number of entries that can be inserted without
the table having to grow.
Rationale:
The bottom of p.283 is user-oriented, the top is implementation-oriented.
User-oriented seems more appropriate.
Current practice:
Symbolics Genera 7.4 adheres to HASH-TABLE-SIZE:INTENDED-ENTRIES.
Other implementations were not surveyed.
Cost to Implementors:
At worst adding a multiplication to MAKE-HASH-TABLE.
Cost to Users:
Probably none, but it is hard to predict.
Cost of non-adoption:
Implementations will probably vary in which of the two interpretations
they believe. The language standard will not be self-consistent.
Performance impact:
None of any significance.
Benefits/Esthetics:
More self-consistent language.
Discussion:
None.
∂21-Mar-89 1629 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Mar 89 16:29:22 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 562415; Tue 21-Mar-89 19:29:06 EST
Date: Tue, 21 Mar 89 19:28 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
To: X3J13@SAIL.STANFORD.EDU
References: <19890317213333.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890322002858.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
This version is edited to clarify that the semantics of simple-array
are not being changed, and supersedes version 8 which you already saw.
Issue: ADJUST-ARRAY-NOT-ADJUSTABLE
References: ADJUST-ARRAY (p297), ADJUSTABLE-ARRAY-P (p293),
MAKE-ARRAY (pp286-289), simple arrays (p28, 289)
Category: CLARIFICATION
Edit history: 22-Apr-87, Version 1 by Pitman
15-Nov-88, Versions 2a,2b,2c by Pitman
02-Dec-88, Version 3 by Pitman
11-Jan-89, Version 4 by Pitman
16-Jan-89, Version 5, by Gabriel. Amended at the meeting to shorten.
23-Jan-89, Version 6, by Moon. Shorten without the bug introduced
by the amendment, add clarification of SIMPLE-ARRAY type.
15-Feb-89, Version 7, by Pitman. Minor changes per comments from
RPG and Dalton.
11-Mar-89, Version 8, by Pitman. Change category, add endorsements.
17-Mar-89, Version 9, by Moon, fix wording and examples to make it
clear that the semantics of simple-array is unchanged.
Problem Description:
The description of the :ADJUSTABLE option to MAKE-ARRAY on p288
says that ``the argument, if specified and not NIL, indicates that
it must be possible to alter the array's size dynamically after
it is created. This argument defaults to NIL.''
The description of the :ADJUSTABLE option does not say what
MAKE-ARRAY will do if the argument is unsupplied or explicitly NIL.
The description of ADJUSTABLE-ARRAY-P on p293 says that it is
true ``if the argument (which must be an array) is adjustable, and
otherwise false.'' However, the description of MAKE-ARRAY makes
it clear that this is not necessarily the same as asking if
the array was created with :ADJUSTABLE T. If ADJUSTABLE-ARRAY-P
returns NIL, you know that :ADJUSTABLE NIL was supplied (or no
:ADJUSTABLE option was supplied), but if ADJUSTABLE-ARRAY-P returns
T, then there is no information about whether :ADJUSTABLE was used.
The description of ADJUST-ARRAY on pp297-298 says that it is
``not permitted to call ADJUST-ARRAY on an array that was not
created with the :ADJUSTABLE option.'' This is inconsistent with
ADJUSTABLE-ARRAY-P.
A problem which comes up in practice is that some programmers
expect runtime error checking if they have done
(MAKE-ARRAY ... :ADJUSTABLE NIL) and they later try to adjust
the array using ADJUST-ARRAY.
The definition of the SIMPLE-ARRAY type and its subtypes needs
clarification of its relationship to adjustability.
Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE:CLARIFY):
1. ADJUSTABLE-ARRAY-P is true of all arrays created with a true
:ADJUSTABLE option to MAKE-ARRAY. Whether ADJUSTABLE-ARRAY-P is
true of some other arrays is unspecified.
2. If MAKE-ARRAY is called with the :ADJUSTABLE, :FILL-POINTER,
and :DISPLACED-TO arguments each either unspecified or false, the
resulting array is a simple array. (This just repeats what CLtL
says on page 289, it's here to aid in understanding the next point.)
3. If MAKE-ARRAY is called with one or more of the :ADJUSTABLE,
:FILL-POINTER, or :DISPLACED-TO arguments true, whether the
resulting array is simple is unspecified.
4. ADJUST-ARRAY ``should signal'' an error if ADJUSTABLE-ARRAY-P
of its first argument is false. ADJUST-ARRAY must not signal an
`array not adjustable' error if ADJUSTABLE-ARRAY-P of its first
argument is true.
5. The value of ADJUSTABLE-ARRAY-P on a simple array is unspecified.
Note: ``should signal'' is taken from the new error terminology.
It means that in ``safe code'' (code compiled with highest safety)
an error must be signalled, but that in unsafe code (code not compiled
with highest safety), an error might or might not be signalled.
Clarifications and Logical Consequences:
a. Whether an array can be both simple and adjustable is unspecified.
b. There is no specified way to create an array for which ADJUSTABLE-ARRAY-P
definitely returns NIL.
c. There is no specified way to create an array that is non-simple.
d. This legitimizes ADJUSTABLE-ARRAY-P as an appropriate predicate to
determine whether ADJUST-ARRAY will reliably succeed.
e. If ADJUST-ARRAY is invoked on an array that was created without
supplying :ADJUSTABLE true, an `array not adjustable' error
``should be signalled'' unless ADJUSTABLE-ARRAY-P returns true on
that array (in which case it must not signal an `array not adjustable'
error).
f. There is no change to the meaning of the type SIMPLE-ARRAY, only
a clarification that a conforming program cannot assume that any
array is not simple.
Rationale:
This effectively makes the status quo explicit. This preserves the
raison d'etre of simple arrays, which is to provide a portable interface
to implementation-dependent specialized arrays that trade decreased
functionality for faster access.
A proposed alternative was to specify a way to create an array that is
guaranteed not to be simple. This would have required large changes
to some implementations and would be of little benefit to users.
Users need to know that certain arrays are simple, so they can put in
declarations and get higher performance, but users have no need to be
able to create arrays that are definitely non-simple (for lower
performance) or definitely non-adjustable (to cause errors).
Examples:
1. The following program is conforming. It is unspecified which branch
of the IF it follows.
(defun double (a)
(if (adjustable-array-p a)
(adjust-array a (* (length a) 2))
(let ((new (make-array (* (length a) 2))))
(replace new a :end1 (length a))
new)))
(double (make-array 30))
2. The following program is conforming. In no implementation is the
type declaration violated.
(let ((a (make-array 100)))
(declare (simple-array a))
(frob a))
3. The following program is non-conforming. The consequences of this
program are undefined because the type declaration is violated in some
valid implementations.
(let ((a (make-array 100 :adjustable t)))
(declare (simple-array a))
(frob a))
Current Practice:
Probably everyone is compatible with this proposal.
Symbolics Genera makes :ADJUSTABLE NIL arrays adjustable in most cases,
and ignores adjustability in deciding whether an array is simple,
and is compatible with this proposal.
Lucid, IIM, and Symbolics Cloe make :ADJUSTABLE NIL arrays non-adjustable
in all cases, and make all arrays non-simple unless the Common Lisp
language requires them to be simple, and are compatible with this proposal.
Cost to Implementors:
It's in principle possible that some implementation would have to change,
but in practice there are no known implementations that would have to change.
Cost to Users:
None. This is a fully compatible change from the user's standpoint.
Benefits:
Users would know what to expect.
Non-Benefits:
Users who expect adjusting arrays created with :ADJUSTABLE NIL to signal
an error would not get the desired error checking.
Aesthetics:
Most people believe the status quo is unaesthetic. Having an aspect of
the language explicitly unspecified is more aesthetic than having it
implicitly unspecified on account of vague or inconsistent documentation.
Discussion:
Pitman, Moon, Gabriel, and Steele support this amended proposal.
MACSYMA ran into portability problems due to the status quo.
If the issue had been documented, that would have helped.
Encouraging implementations that are able to at least make
(MAKE-ARRAY ... :ADJUSTABLE NIL) create non-adjustable arrays
where possible would help, too.
We considered proposals to incompatibly change this primitive in a
variety of ways, but the community was very split with strong proponents
and opponents of each alternate proposal.
The overriding concern driving this proposal is that Symbolics
has asserted that most of the other really interesting proposals would
likely involve a sizable cost to implementors (and their installed bases)
to implement what were judged by some as gratuitous changes from the
status quo.
Pitman wishes some of the other proposals were economically feasible to
pursue but reluctantly agrees that maintaining (and clearly documenting)
the status quo is probably the most reasonable avenue left to us.
∂21-Mar-89 1732 CL-Compiler-mailer **DRAFT** issue CLOS-MACRO-COMPILATION, version 2
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Mar 89 17:32:46 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 562475; Tue 21-Mar-89 20:32:29 EST
Date: Tue, 21 Mar 89 20:32 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: **DRAFT** issue CLOS-MACRO-COMPILATION, version 2
To: cl-compiler@SAIL.STANFORD.EDU
cc: x3j13@SAIL.STANFORD.EDU
In-Reply-To: <8903132248.AA02496@defun.utah.edu>
Message-ID: <19890322013216.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
I would go with MINIMAL for now. It leaves a lot of behavior
unspecified, and we can fill in that behavior later when we
add metaobjects to the standard.
Relatively small comments:
The compiler should be allowed to warn, but not error, about
failures of lambda-list congruence between methods or generic
functions in the file being compiled and methods or generic
functions in the Lisp doing the compilation. When you say
the compiler may not "perform tests" between these, it's not
clear whether you mean to rule out only errors or both errors
and warnings.
The only thing here that might be overspecification is allowing a
DEFINE-METHOD-COMBINATION to be used later in the same compilation.
However, I see no real harm in that, and it would often be
convenient for programmers, so leave it. But if someone else
moves to remove it, I will not object.
Evaluation of the form in EQL parameter specializer names in DEFMETHOD
needs to be covered. I think this is tied up with the pending compiler
committee issue DEFCONSTANT-VALUE (whose version 2 writeup I don't like,
it's too messy). The choices seem to be to require the form in an EQL
parameter specializer name to be evaluable at compile time, to require
it to depend only on constants defined in the file being compiled, or to
permit its evaluation to be deferred until load time. I don't like the
first choice. I think for both DEFCONSTANT and EQL the semantics should
be as if it were never evaluated until load time, with the compiler
allowed to evaluate it sooner only if it can prove that that does not
change the semantics. I'd be happier if the mechanism the compiler
uses to do this tentative evaluation were made available to the user,
but that can be deferred until metaobjects.
con-Mar-89 2048 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 21 Mar 89 20:48:46 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA01278g; Tue, 21 Mar 89 20:43:21 PST
Received: by challenger id AA22664g; Tue, 21 Mar 89 20:38:38 PST
Date: Tue, 21 Mar 89 20:38:38 PST
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8903220438.AA22664@challenger>
To: x3j13@sail.stanford.edu
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
People have continued to debate this issue. Part of the confusion is
what CLtL really says about simple arrays and adjustability. The
cause of the confusion is that various people have advanced difficult
to understand arguments and proposals (myself included).
As mentioned in the statement of ADJUST-ARRAY-NOT-ADJUSTABLE (Version
9), I agreed to support it, and I also agreed that it was a
clarification and not a change,
Because I had become confused by the issue, I decided to go back to
CLtL to find the consistent readings of the passages on simple arrays
and adjustability. As part of this exercise I tried to write up an
analysis of the possible interpretations of the the statements in
question. I often use this hermeneutical act to understand difficult
issues.
The result is that I think there are exactly two plausible consistent
readings, with one much more plausible than the other. Both readings
are inconsistent with ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9).
Therefore, I conclude that ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9) is
a change, not a clarification, and I must withdraw my agreement that
it is a clarification.
Whether we wish to adopt it is another question, to which I offer no
specific comment or suggestion. I am convinced that if some people
have read CLtL as meaning what ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
states and implemented simple arrays that way, we are in quite a bind.
The only minor comment I have is a general one: We should be wary of
changes (rather than clarifications) at this stage of standardization.
This message is very long and contains lots of close reasoning and
boring details. By its length and detail some might read it as a
strong criticism of the authors of ADJUST-ARRAY-NOT-ADJUSTABLE
(Version 9) - it really isn't (in fact, before I this exercise I
believed that the contents of ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
would be one of the plausible interpretations). It is simply what I
found and how I found it.
If you want to get to the heart of the matter, ask your text editor to
search for <<yoo-hoo>> and start reading there.
*************************
* Start of the Analysis *
*************************
In this message I will use the notation (S-i) to name statements;
(S-8) is to be read as ``statement 8.'' I will use (I-i-j) to name
interpretations of statments; (I-8-2) is to be read as ``the second
interpretation of statement 8.'' (I-7;8-4) is to be read as ``the
fourth interpretation of the statements 7 and 8 taken together.'' I
will use (*I-i-j) to name incorrect interpretations of statements;
(*I-8-2) is to be read as ``the (incorrect) second interpretation of
statement 8.'' I will use (C-i[J1,...,Jn) to name conclusions derived
from statements; (C-2[S-1,I-8-2]) is to be read as ``conclusion 2
derived from statement 1 and the second interpretation of statement
8.''
There are several relevant statements in CLtL.
(S-1) [from Page 28] An array that is not displaced to another array,
has no fill pointer, and is not to have its size adjusted dynamically
after creation is called a simple array.
(S-2) [from Page 288] :ADJUSTABLE: This argument, if specified and not
NIL, indicates that it must be possible to alter the array's size
dynamically after it is created.
(S-3) [immediately follows (S-2)] This argument defaults to NIL.
(S-4) [from Page 289] If MAKE-ARRAY is called with the :ADJUSTABLE,
:FILL-POINTER, and :DISPLACED-TO arguments each either unspecified or
false, the resulting array is a simple array.
(S-5) [from Page 293] This predicate [ADJUSTABLE-ARRAY-P] is true if
the argument (which must be an array) is adjustable, and otherwise
false.
(S-6) [from Page 297] It is not permitted to call ADJUST-ARRAY on an
array that was not created with the :ADJUSTABLE option.
(S-7) [immediately follows (S-6)] The predicate ADJUSTABLE-ARRAY-P may
be used to determine whether or not an array is adjustable.
First, let's look at the various interpretations of these statements.
***************************
* Interpretation of (S-1) *
***************************
The statement (S-1) appears to be in the form of a definition.
However, the phrase ``is called'' could be taken as a non-standard way
to introduce a definition and might instead be taken as a conditional
statement: Schematically, ``X's are called Y's'' could be taken to
mean ``If something is an X, then it is a Y.''
I don't think this is a plausible reading in a programming language
specification. Consider this sentence:
``A number that is divisible by 9 is called a well-tempered number.''
I think this is a fair definition. Certainly we would say that, by
this definition, the number 11 is not a well-tempered number.
Nevertheless, a possible interpretation of (S-1) could be:
(*I-1-1) If an array is not displaced to another array, has no fill
pointer, and is not to have its size adjusted dynamically after
creation, it is a simple array (and there may be simple arrays that do
not satisfy these properties).
However, if we look at the other statements in Chapters 2 and 17 we
see the use of ``is called'' throughout in what appears to be a
definitional sense. If (S-1) lacks definitional force, then so do
these statements:
Page 29: One-dimensional arrays are called vectors in Common Lisp
and constitute the type VECTOR (which is therefore a subtype
of ARRAY).
Page 29: All implementations provide specialized arrays for the cases
when the components are characters (or rather, a special subset of the
characters); the one-dimensional instances of this specialization are
called strings.
Page 29: All implementations are also required to provide specialized
arrays of bits, that is, arrays of type (ARRAY BIT); the
one-dimensional instances of this specialization are called bit
vectors.
Page 286: One-dimensional arrays are called vectors.
Page 286: Vectors whose elements are restricted to type STRING-CHAR
are called strings.
Page 286: Vectors whose elements are restricted to type BIT are called
bit-vectors.
Nothing but one-dimensional arrays are called or considered vectors,
and so I think ``is called'' can reasonably be interpreted only as
definitional.
I believe (*I-1-1) is not reasonable by the two arguments of incorrect
form for a conditional and the use of the ``is called'' form in
definitional senses elsewhere in Chapter 2.
I believe the definitional interpretation of (S-1) is this:
(I-1-1.5) Definition: An array is called a simple array if and only if
the array is not displaced to another array, has no fill pointer, and
is not to have its size adjusted dynamically after creation.
Further, I think the obvious meaning of (S-1) is this:
(I-1-2) Definition: An array is called a simple array if and only if
the array is not displaced to another array, has no fill pointer, and
cannot have its size adjusted dynamically after creation.
Another interpretation of (S-1) is possible. Note that the that the
phrase ``is not to have its size adjusted dynamically after creation''
is used rather than the less equivocal ``cannot have its size adjusted
dynamically after creation.'' One way to understand this phrasing is
as a stylistic device to produce the relatively uniform pattern ``an
array that is, ..., has, ... and is...'' rather than the relatively
non-uniform pattern ``an array that is, ..., has, ... and can....'' I
believe that this stylistic nuance is what Steele had in mind, but an
alternative is possible.
The alternative is derived as follows: If something ``is not to be''
acted upon in some particular way, then it is not the *intention* of
the actor to act upon that thing in that way. Therefore, we have the
alternative interpretation:
(I-1-3) Definition: An array is called a simple array if and only if
the array is not displaced to another array, has no fill pointer, and
is not intended to have its size adjusted dynamically after creation.
This results in a curious meaning for ``simple array.'' A simple array
is a legitimate type (SIMPLE-ARRAY appears on Page 34 in the sentence,
``SIMPLE-ARRAY is a subtype of ARRAY.'' It also appears on page 43 as
one the Common Lisp Standard Type Specifiers, and on Page 42 it
states, ``in Common Lisp, types are named by Lisp objects,
specifically symbols and lists, called type specifiers.''), and so it
must be possible to make such an array and to test objects for this
type. If (typep A 'simple-array) is true, then A is an array that,
among other things, was *intended* to not have its size altered
dynamically after creation.
There is another interpretation of (S-1), which interprets ``is not
to have'' as ``doesn't happen to have.''
(*I-1-4) An array that is not displaced to another array, has no fill
pointer, and doesn't happen to have its size adjusted dynamically
after creation is called a simple array.
I think this is an unlikely interpretation because it is clear that a
simple array can be created, and at the point of creation MAKE-ARRAY
would not know whether the size will happen to be adjusted later.
There is yet another interpretation of (S-1), but it cannot be presented
easily until after some other arguments have been made.
***************************
* Interpretation of (S-2) *
***************************
The statement (S-2) states that the argument :ADJUSTABLE can be used
to create an array whose size can be altered dynamically after
creation.
If (I-1-2) is the correct interpretation, then supplying a non-NIL
:ADJUSTABLE argument results in an array whose size *can* be altered
dynamically after creation, and so an array made this way is not a
simple array.
If (I-1-3) is the correct interpretation, then supplying a non-NIL
:ADJUSTABLE argument results in an array that is *intended* to have
its size altered dynamically after creation, and so an array made this
way is not a simple array.
(C-1[I-1-2,I-1-3,S-2]) Supplying a non-NIL :ADJUSTABLE argument to
MAKE-ARRAY results in a non-simple array. The basis for this
conclusion is the definitional nature of (S-1) regardless of the two
variants of the definition.
In fact, if we look at the statements regarding :FILL-POINTER and
:DISPLACED-TO, we see that if either of them is supplied and true, the
resulting array is also not simple (using the same argument used for
:ADJUSTABLE).
Therefore,
(C-2[I-1-2,I-1-3]) An array created with any one of :ADJUSTABLE,
:FILL-POINTER, and :DISPLACED-TO specified and non-NIL is not simple.
***************************
* Interpretation of (S-3) *
***************************
The statement (S-3) has a single interpretation.
***************************
* Interpretation of (S-4) *
***************************
The statement (S-4) states that if all three of the :ADJUSTABLE,
:FILL-POINTER, and :DISPLACED-TO arguments are unspecified or false, a
simple array is produced.
Combining this with (C-2) we get:
(C-3[S-4,C-2]) An array created with any one of :ADJUSTABLE,
:FILL-POINTER, and :DISPLACED-TO specified and non-NIL is not simple.
The force of (S-2) and (S-4) is that only a part of the type structure
of arrays is specified. There is definitely a way to create a simple
array, and definitely ways to create non-simple arrays, but whether
non-simple arrays are further distinguished based on the arguments
:ADJUSTABLE, :FILL-POINTER, and :DISPLACED-TO is not specified.
***************************
* Interpretation of (S-5) *
***************************
We will return to statement (S-5) later. Its interpretation is clear,
but which arrays are adjustable is not.
***************************
* Interpretation of (S-6) *
***************************
Statement (S-6) is quite tricky.
The problem is with the phrase ``is not permitted''; the question is
whether it is synonymous with ``is an error'' or whether it is
stronger.
The case for ``is not permitted"" being stronger than ``is an error''
is very compelling, I feel. First, taken as an English phrase, it is
strong: If you are not permitted to call ADJUST-ARRAY, then you do not
have permission to call it; in other words, you are not allowed to
call it, calling it is not tolerated, consent was not given to call
it, you do not have license to call it, you are not authorized to call
it, you do not have the opportunity to call it, it is not possible to
call it.
Second, ``is not permitted'' is not listed on Page 6 as one of the
phrases synonymous with ``is an error.'' If Steele wanted to actually
prohibit something, he would not be able to use the relatively
intuitive ``must not'' since that means ``is an error,'' which can be
taken to mean ``is allowed.'' That is, within the linguistic bounds of
CLtL it is possible to interpret the statement ``you must not do X''
as ``you are allowed to do X.''
The phrase ``is not permitted'' is used elsewhere in CLtL. The most
directly informative usage is on Page 72:
``The names NIL and T are constants in Common Lisp. Although they are
symbols like any other symbols, and appear to be treated as variables
when evaluated, it is not permitted to modify their values. See
DEFCONSTANT.''
Changing the values of NIL and T is a pretty serious offense. Steele
could have directly used the wording ``is an error,'' but he chose a
phrase not formally defined. He also could have said that NIL and T
are constants exactly like those defined by DEFCONSTANT, but he chose
informal wording that is stronger than ``is an error.'' Finally, the
advice to see DEFCONSTANT is given, almost as an afterthought.
Here is the main interpretation of (S-6):
(I-6-1) Calling ADJUST-ARRAY on an array that was not created with the
:ADJUSTABLE option is prohibited.
An array is ``adjustable'' if it is capable of being adjusted.
ADJUST-ARRAY is the only function in Common Lisp that can adjust an
array. Therefore, if ``calling ADJUST-ARRAY...is prohibited'' in some
situation, then that array is not adjustable in that situation. The
situation pointed out by (I-6-1) is that the ``array ... was not
created with the :ADJUSTABLE option.''
Combining this with (S-2) we get:
(C-4[I-6-1,S-2]) An array is adjustable if and only if the array was
created with the :ADJUSTABLE option.
Now let's look at the case for (S-6) being permissive.
The remark ``see DEFCONSTANT'' could be taken to mean that NIL and T
are simply constants and are to be treated that way, no more, no less.
Under DEFCONSTANT it states that altering the value of a constant ``is
an error.''
So here is the alternative:
(I-6-2) Calling ADJUST-ARRAY on an array that was not created with the
:ADJUSTABLE option is an error (that is, it is allowed).
***************************
* Interpretation of (S-7) *
***************************
On the face of it, (S-7) is a restatement of (S-5). The two
alternative readings result from either taking its presence as
relevant or irrelevant. That is, one can either believe that (S-7)
conveys some new information by its location relative to other
statements or that the reading of CLtL is as if (S-7) were deleted
I believe that essentially deleting (S-7) is not reasonable, mostly
because Steele is a better writer than that interpretation would
imply.
The fact that (S-7) immediately follows (S-6) implies that there is
some relation between them. In a two-sentence paragraph it is odd to
have the second sentence add no information to the first. The obvious
relation is that ADJUSTABLE-ARRAY-P is the predicate that can be used
to determine whether it is permitted to call ADJUST-ARRAY.
(I-7-1) ADJUSTABLE-ARRAY-P can be used to determine whether or not
ADJUST-ARRAY is permitted.
Consider (I-6-1). Using (C-4), since ADJUST-ARRAY can be called on
exactly those arrays that were created with the :ADJUSTABLE option,
and since ADJUSTABLE-ARRAY-P can be used to determine whether
ADJUST-ARRAY can be used, we get:
(C-5[C-4,S-5]) ADJUSTABLE-ARRAY-P can be used to determine whether or
not an array was created with the :ADJUSTABLE option.
Given this, following (S-6) with (S-7) is natural, because it serves
to reinforce the interpretation (I-6-1) because ADJUSTABLE-ARRAY-P
talks about adjustability.
Let's put (I-6-1), (I-7-1), and (C-5) together:
(I-6;7-1) ADJUST-ARRAY can be called only on adjustable arrays, that
is, only on arrays created with the :ADJUSTABLE option.
ADJUSTABLE-ARRAY-P can be used to determine whether an array was
created with the :ADJUSTABLE option.
Consider (I-6-2). The effect of (I-7-1) is to reinforce the
interpretation (I-6-2), because (S-7) states that ADJUSTABLE-ARRAY-P
must be used to determine adjustability, not the use of the
:ADJUSTABLE argument in MAKE-ARRAY.
We can rephrase (I-6-2) and (I-7-1) as follows:
(I-6;7-2) Calling ADJUST-ARRAY on an array that was not created with
the :ADJUSTABLE option is an error (that is, it is allowed); and
ADJUSTABLE-ARRAY-P can be used to determine whether or not it is
allowed.
**************************
* Interpretation of CLtL *
**************************
Now let's look at (I-1-2) and (I-1-3).
(I-1-2) can be taken either under (I-6;7-1) or under (I-6;7-2).
Under (I-6;7-1) and recalling (C-2), (C-3), and (C-4) we get:
Position 1: The only simple arrays are those created with the
:ADJUSTABLE, :FILL-POINTER, and :DISPLACED-TO arguments each either
unspecified or false. All simple arrays are not adjustable. An array
is adjustable if and only if it was created with the :ADJUSTABLE
option. ADJUSTABLE-ARRAY-P is false of all simple arrays.
There is an affinity between (I-1-2) and (I-6;7-1) because the
:ADJUSTABLE argument states whether it is possible to adjust the
array.
Under (I-6;7-2) and recalling (C-2) and (S-5), we get:
Position 2: The only simple arrays are those created with the
:ADJUSTABLE, :FILL-POINTER, and :DISPLACED-TO arguments each either
unspecified or false. A simple array may or may not be adjustable. An
array created with the :ADJUSTABLE option unspecified or NIL might be
adjustable. ADJUSTABLE-ARRAY-P can be used to determine whether an
array is adjustable.
This is weak because (I-1-2), (S-2), and (S-4) taken together implies
that the :ADJUSTABLE argument controls adjustability. (I-6-2) implies
that :ADJUSTABLE unspecified or NIL might result in an adjustable
array.
(I-1-3) must be considered under both (I-6;7-1) and (I-6;7-2).
Looking at (I-1-3) with (I-6;7-1), we get Position 1 again, because the
:ADJUSTABLE arguments signals intent to adjust an array. Here,
(I-6;7-1) implies that one cannot call ADJUST-ARRAY on an array that
was not intended to be adjusted. I feel this is a weak pair of
interpretations.
Looking at (I-1-3) with (I-6;7-2), we get Position 2 again. Here it is
allowed to call ADJUST-ARRAY on an array that wasn't intended to be
adjusted. There is some affinity between (I-1-3) and (I-6;7-2) because
the :ADJUSTABLE argument signals intention only. The only intention
that is required to be acted upon is specifying a non-NIL :ADJUSTABLE
argument, which must result in an adjustable array. If your intention
is to not adjust the array, you should not care whether it is actually
adjustable. Therefore, (I-6-2) is a sensibly paired with (I-1-3).
The variations of ``can not be adjusted'' and ``not intended to be
adjusted'' have little differential effect on the final
interpretations except insofar as Position 1 is stronger when paired
with (I-1-2) and Position 2 is stronger with (I-1-3). I believe that
the strength of the argument regarding ``is not permitted'' coupled
with the weakness the plausibility of a type being defined with
respect to intention combine to make Position 1 the stronger
interpretation.
*************************************
* Interpretation of (S-1) Revisited *
*************************************
Given the clearly definitional nature of (S-1), let's look at the
question of whether there is any basis in CLtL for an array created
with one of :ADJUSTABLE, :FILL-POINTER, and :DISPLACED-TO specified
and non-NIL to be simple.
The reasoning for such a situation is as follows: Under Position 2 it
is possible for a simple array to be adjustable. The expression
(MAKE-ARRAY n :ADJUSTABLE NIL) creates a simple array under Position
2, and so why shouldn't (MAKE-ARRAY n :ADJUSTABLE T), since MAKE-ARRAY
probably ignores the :ADJUSTABLE argument.
For this to be allowed, (S-1) must be a partial or conditional
definition. That is, (S-1) might be definitional, but only for
certain implementations, or part of the definition might apply only
for certain implementations. The remainder of the paragraph that
starts with (S-1) continues as follows:
(S-8) The user may provide declarations that certain arrays will be
simple.
(S-9) Some implementations can handle simple arrays in an especially
efficient manner; for example, simple arrays may have a more compact
representation than non-simple arrays.
(S-8) and (S-9) clearly imply that the reason for simple arrays is
efficiency. (S-8) talks about declarations provided by the user. When
a Common Lisp programmer provides a declaration that does not have
semantic import, this can signal only intention. Therefore, the
interpretation (I-1-3) would seem to make sense.
I believe that nothing in (S-8) and (S-9) alters the definitional
nature of (S-2). The most (S-8) and (S-9) could do is limit its
applicability of the definition. That is, neither (S-8) nor (S-9)
imply that (S-1) is not a definition, but they could modify the
conditions that the definition predicates.
The paragraph starting with (S-1) could be taken as a description of a
type that is useful only in implementations that act differently
according to the user's intentions as signaled by declarations. Since
(S-4) requires that some arrays be simple, implementations that have
no use for simple arrays are forced to have them.
Another interpretation of (S-1) is then:
(*I-1-5) An array that is not displaced, has no fill pointer, and has
been created with the intention not to have its size altered
dynamically after creation in an implementation that honors
declarations is a simple array.
I think this is a far-fetched reading, particularly since Steele
is capable of stating something like this much more precisely than
with the series (S-1), (S-8), and (S-9).
***********************
* End of the Analysis *
***********************
<<yoo-hoo>>
For those of you who could not stand to read the hermeneutic
arguments, here are the only two consistent readings of CLtL regarding
simple arrays and adjustability. I believe that Position 1 has the
stronger set of arguments behind it and is, I believe, the preferred
reading:
Position 1: The only simple arrays are those created with the
:ADJUSTABLE, :FILL-POINTER, and :DISPLACED-TO arguments each either
unspecified or false. All simple arrays are not adjustable. An array
is adjustable if and only if it was created with the :ADJUSTABLE
option. ADJUSTABLE-ARRAY-P is false of all simple arrays.
Position 2: The only simple arrays are those created with the
:ADJUSTABLE, :FILL-POINTER, and :DISPLACED-TO arguments each either
unspecified or false. A simple array may or may not be adjustable. An
array created with the :ADJUSTABLE option unspecified or NIL might be
adjustable. ADJUSTABLE-ARRAY-P can be used to determine whether an
array is adjustable.
Here are the points of ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9). I will
note whether each point is consistent with each of the two Positions
so that Version 9 can be seen to be a change rather than a
clarification:
1. ADJUSTABLE-ARRAY-P is true of all arrays created with a true
:ADJUSTABLE option to MAKE-ARRAY. Whether ADJUSTABLE-ARRAY-P is
true of some other arrays is unspecified.
This weakly contradicts Position 1, since Position 1 states which
arrays are adjustable and which aren't. It is consistent with
Position 2.
2. If MAKE-ARRAY is called with the :ADJUSTABLE, :FILL-POINTER,
and :DISPLACED-TO arguments each either unspecified or false, the
resulting array is a simple array. (This just repeats what CLtL
says on page 289, it's here to aid in understanding the next point.)
This is simply (S-4).
3. If MAKE-ARRAY is called with one or more of the :ADJUSTABLE,
:FILL-POINTER, or :DISPLACED-TO arguments true, whether the
resulting array is simple is unspecified.
This contradicts both Position 1 and Position 2.
4. ADJUST-ARRAY ``should signal'' an error if ADJUSTABLE-ARRAY-P
of its first argument is false. ADJUST-ARRAY must not signal an
`array not adjustable' error if ADJUSTABLE-ARRAY-P of its first
argument is true.
This is consistent with both Position 1 and Position 2.
5. The value of ADJUSTABLE-ARRAY-P on a simple array is unspecified.
This contradicts Position 1 and is consistent with Position 2.
Let's also look at the ``Clarifications and Logical Consequences''
presented in the proposal:
a. Whether an array can be both simple and adjustable is unspecified.
This contradicts Position 1 and is consistent with Position 2.
b. There is no specified way to create an array for which ADJUSTABLE-ARRAY-P
definitely returns NIL.
This contradicts Position 1 and is consistent with Position 2.
c. There is no specified way to create an array that is non-simple.
This contradicts both Position 1 and Position 2. In fact, this
contradicts (S-1) under any reasonable interpretation of it.
d. This legitimizes ADJUSTABLE-ARRAY-P as an appropriate predicate to
determine whether ADJUST-ARRAY will reliably succeed.
This is consistent with both Position 1 and Position 2.
e. If ADJUST-ARRAY is invoked on an array that was created without
supplying :ADJUSTABLE true, an `array not adjustable' error
``should be signaled'' unless ADJUSTABLE-ARRAY-P returns true on
that array (in which case it must not signal an `array not adjustable'
error).
This is consistent with both Position 1 and Position 2.
Therefore, ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9) is a change to
CLtL, and in fact, Point 3 (and Consequence C) is a major change.
-rpg-
∂22-Mar-89 0816 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu Information request
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Mar 89 08:16:27 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA22050; Wed, 22 Mar 89 08:16:08 -0800
Message-Id: <8903221616.AA22050@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Wed, 22 Mar 89 08:15:52 PST
Received: by BYUADMIN (Mailer R2.01A) id 5136; Wed, 22 Mar 89 09:15:21 MST
Date: Wed, 22 Mar 89 09:43:38 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"William J. Joel" <JZEM%MARIST.BITNET@forsythe.stanford.edu>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "William J. Joel" <JZEM%MARIST.BITNET@forsythe.stanford.edu>
Subject: Information request
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
I am looking for references relating to any aspect of the following
topics:
- mathematical notations for computer graphics
- logic programming (Prolog) and computer graphics
- logic programming (Prolog) and geometry (Euclidean)
Please send any info to my email address, directly. Thanks!
Bill Joel
jzem@marist.bitnet
∂22-Mar-89 0845 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Mar 89 08:45:33 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 562901; Wed 22-Mar-89 11:44:59 EST
Date: Wed, 22 Mar 89 11:44 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
To: Richard P. Gabriel <rpg@lucid.com>
cc: x3j13@SAIL.STANFORD.EDU
In-Reply-To: <8903220438.AA22664@challenger>
Message-ID: <19890322164453.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 21 Mar 89 20:38:38 PST
From: Richard P. Gabriel <rpg@lucid.com>
[603 lines deleted]
Therefore, ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9) is a change to
CLtL, and in fact, Point 3 (and Consequence C) is a major change.
Show us any conforming program that would be harmed by this change (if
it is a change, and I don't believe your arguments that it is a change)
"c. There is no specified way to create an array that is non-simple."
∂22-Mar-89 0931 X3J13-mailer Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Mar 89 09:31:05 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 562950; Wed 22-Mar-89 12:30:11 EST
Date: Wed, 22 Mar 89 12:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 2)
To: X3J13@SAIL.STANFORD.EDU
cc: Pavel.pa@XEROX.COM, GSB@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <19890322172956.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
This proposal didn't quite make it to the January meeting, due to
unclear responsibilities for who was supposed to update it from the
discussion. I have filled the gap and made the changes implied by the
discussion back in December of last year. We can't vote on this if
someone invokes the two-week rule, but perhaps no one will.
Issue: SETF-MULTIPLE-STORE-VARIABLES
References: CLtL, pp.93-107
Lisp Pointers, v2n2, pp.27-41
Category: ADDITION
Edit history: Version 1, 5-Dec-88, Pavel
Version 2, 22-Mar-89, Moon, simplify, update from discussion
Problem description:
The description of GET-SETF-METHOD-MULTIPLE-VALUE on page 107 of CLtL
states that there are no cases in Common Lisp that allow multiple values
to be stored into a generalized variable. This is seen by some as an
arbitrary decision in light of the fact that a very reasonable semantics
exists for multiple values being assigned by several Common Lisp macros,
including SETF. The rationale on page 103 of CLtL suggests that this
decision might be changed in the future.
Proposal (SETF-MULTIPLE-STORE-VARIABLES:ALLOW):
Extend the semantics of the macros SETF, PSETF, SHIFTF, ROTATEF, and
ASSERT to allow "places" whose SETF methods have more than one "store
variable". In such cases, the macros accept as many values from the
newvalue form as there are store variables. As usual, extra values
are ignored and missing values default to NIL.
Extend the long form of DEFSETF to allow the specification of more
than one "store variable", with the obvious semantics.
Clarify that GET-SETF-METHOD signals an error if there would be more
than one store-variable.
Test Cases/Examples:
(defstruct region width height)
(defun region-size (region)
(values
(region-width region)
(region-height region)))
(defsetf region-size (region) (width height)
`(values
(setf (region-width ,region) ,width)
(setf (region-height ,region) ,height)))
(setf my-reg (make-region :width 10 :height 20))
=> #S(REGION :WIDTH 10 :HEIGHT 20)
(region-size my-reg)
=> 10
20
(setf (region-size my-reg) (values 30 40))
=> 30
40
(region-size my-reg)
=> 30
40
Rationale:
This change removes an artificial restriction on the semantics of
several Common Lisp macros, allowing a broader set of contexts in
which generalized variables can be used. For example, it is not
difficult to write a reasonable SETF method for the VALUES function,
yielding a powerful MULTIPLE-VALUE-SETF form:
(setf (values (car a) (gethash b 'c) (aref d 13))
(some-hairy-computation))
In the language as currently defined, this example would have to be
written:
(multiple-value-bind (x y z)
(some-hairy-computation)
(setf (car a) x
(gethash b 'c) y
(aref d 13) z))
Many other (perhaps more compelling) examples of generalized variables
holding more than one value can easily be imagined. Their use,
however, is severely discouraged by Common Lisp as defined in CLtL,
since none of the built-in macros will accept them.
The clarification of GET-SETF-METHOD makes explicit what is implied
by CLtL (CLtL uses the word "guarantee", whose relationship to
signalling of errors is unclear).
Current practice:
I do not know of any implementations that allow all of this extension.
Xerox Lisp does not signal an error, but this is probably due to a bug
in GET-SETF-METHOD. Lucid signals an error in GET-SETF-METHOD.
Symbolics Genera supports the proposal in SETF and PSETF, but not in
SHIFTF, ROTATEF, and ASSERT.
Cost to Implementors:
A relatively minor fix to each of the affected macros suffices. For
example, to fix SETF itself, one need only call
GET-SETF-METHOD-MULTIPLE-VALUE instead of GET-SETF-METHOD and emit a
MULTIPLE-VALUE-BIND instead of a LET for binding the store variables.
Cost to Users:
This is an upward-compatible change; no user code must change.
Cost of non-adoption:
Yet another non-uniformity in the language, yet another piece of
mechanism without a clear use (GET-SETF-METHOD-MULTIPLE-VALUE).
Benefits:
Wider applicability of a reasonably nice abstraction, the removal of
an artificial prohibition.
Aesthetics:
People may disagree about whether this is a simplification or not. I
am firmly on the side that believes that such removal of
non-uniformities is a simplifying force in the language.
Discussion:
Pavel supports this proposal.
Moon supports this proposal except he is not sure about the
inclusion of ASSERT.
GSB suggests that this is a clarification rather than an addition,
because the lack of any predefined setf-methods that use multiple
store variables should not mean that SETF, etc. should not work with
such a setf-method if the user defined one. The problem is that CLtL
examples such as the ones for SHIFTF on p.98 and the simplified
definition for SETF on p.107 contradict this proposal, and might have
been taken as specifications, rather than simplified examples, by
some readers.
Predefined SETF methods for such functions as VALUES, CONS, and VECTOR
could have been proposed, but we refrained. This proposal is necessary
to allow the user to write such methods for himself, but if this
proposal is adopted those setf-methods are very easy to write in
a portable fashion.
∂22-Mar-89 1228 @polya.Stanford.EDU:THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu theory calendar
Received: from polya.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Mar 89 12:28:38 PST
Received: from forsythe.Stanford.EDU by polya.Stanford.EDU with SMTP (5.61/25-eef) id AA03451; Wed, 22 Mar 89 12:27:32 -0800
Message-Id: <8903222027.AA03451@polya.Stanford.EDU>
Received: by Forsythe.Stanford.EDU; Wed, 22 Mar 89 12:27:12 PST
Received: by BYUADMIN (Mailer R2.01A) id 1045; Wed, 22 Mar 89 13:26:39 MST
Date: Wed, 22 Mar 89 14:16:25 CST
Reply-To: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>,
"Michael A. Langston" <langston@CS2.WSU.EDU>
Sender: TheoryNet List <THEORYNT%NDSUVM1.BITNET@forsythe.stanford.edu>
Comments: Warning -- original Sender: tag was THEORYNT@YKTVMX
From: "Michael A. Langston" <langston@CS2.WSU.EDU>
Subject: theory calendar
To: Local Distribution <aflb-tn@POLYA.STANFORD.EDU>
I am happy to announce that Jeff Salowe has agreed to maintain a calendar
of theory events for SIGACT News, with regular postings to theorynet as
well. He will be gleaning items from the input I receive for the News,
from the EATCS Bulletin, from ACM HQ and other sources. If you are handling
publicity for a theory conference or for any other theory-related event,
please remember to send a blurb to Jeff at jss2z@mithras.cs.virginia.edu.
-- Mike Langston
∂22-Mar-89 1401 X3J13-mailer **DRAFT** issue: PATHNAME-COMPONENT-CASE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Mar 89 14:01:14 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 563174; Wed 22-Mar-89 17:00:57 EST
Date: Wed, 22 Mar 89 17:00 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: **DRAFT** issue: PATHNAME-COMPONENT-CASE (Version 1)
To: X3J13@SAIL.Stanford.EDU
Message-ID: <890322170040.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
>>> PLEASE DO -NOT- REPLY TO THIS ISSUE NOW <<<
At this point, probably no one will read what you would write
anyway. Instead, think about the issue and organize your thoughts
for in-person discussion at the meeting.
There was a lot of discussion on this issue. The Cleanup committee is
not in agreement on its disposition. However, the issue is a real one
that we cannot afford to overlook. See additional comments at the end
for a survey of points of contention.
-kmp
-----
Issue: PATHNAME-COMPONENT-CASE
References: Pathnames (pp410-413),
MAKE-PATHNAME (p416),
PATHNAME-HOST (p417),
PATHNAME-DEVICE (p417),
PATHNAME-DIRECTORY (p417),
PATHNAME-NAME (p417),
PATHNAME-TYPE (p417)
Category: CHANGE
Edit history: 1-Jul-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
Issues of case in pathnames are a major source of problems.
In some file systems, the canonical case is lowercase, in some
uppercase, in some mixed.
In some file systems, case matters, in others it does not.
(NAMESTRING (MAKE-PATHNAME :NAME "FOO" :TYPE "LISP"))
will produce an `ugly' file name like "FOO.LISP" in many (but not all)
Common Lisp implementations talking to Unix, for example.
(NAMESTRING (MAKE-PATHNAME :NAME "foo" :TYPE "lisp"))
might produce an `ugly' file name like "↑Vf↑Vo↑Vo.↑Vl↑Vi↑Vs↑Vp"
in a Common Lisp implementation talking to a Tops-20.
Problems like this make it difficult to use MAKE-PATHNAME for much of
anything without corrective (non-portable) code.
Other problems occur in merging because doing
(NAMESTRING (MERGE-PATHNAMES (MAKE-PATHNAME :HOST "MY-TOPS-20" :NAME "FOO")
(PARSE-NAMESTRING "MY-UNIX:x.lisp")))
should probably return "MY-TOPS-20:FOO.LISP" but in fact might return
"MY-TOPS-20:FOO.↑Vl↑Vi↑Vs↑Vp" in some implementations.
Problems like this make it difficult to use any merging primitives for
much of anything without corrective (non-portable code).
Proposal (PATHNAME-COMPONENT-CASE:CANONICALIZE):
Designate a treatment for case in pathname components which is
distinct from the treatment of case in the namestrings. The treatment
should be invariant across operating systems.
If a string given to MAKE-PATHNAME, or returned by any of the
PATHNAME-xxx accessor operations, is all uppercase, it is said to
designate a name in the system's "canonical case".
If a string given to MAKE-PATHNAME, or returned by any of the
PATHNAME-xxx accessor operations, is all lowercase, it is said to
designate a name in the system's "anticanonical case".
If a string given to MAKE-PATHNAME, or returned by any of the
PATHNAME-xxx accessor operations, is mixed case, it is said
designate a name in exactly the indicated case.
Functions such as PARSE-NAMESTRING and NAMESTRING which convert
from or to native host syntax will perform any necessary conversions
from internal syntax.
Note: In fact, this proposal does not require an implementation to
change its internal representation. It only requires the CL-defined
accessors to behave as if the internal representation had been changed.
Whether the actual internal representation is changed is still up to an
implementation. A consequence of this is that if pathnames print
in a way that shows the components individually (such as #S), they
are not constrained to print the components in any particular case;
they are constrained only to have definite syntax conventions and to
be able to invert those conventions at the appropriate time. Any change
to the way pathnames print is beyond the scope of this proposal.
Test Case:
(PATHNAME-NAME (PARSE-NAMESTRING "MY-UNIX:/me/foo.lisp")) => "FOO"
(PATHNAME-NAME (PARSE-NAMESTRING "MY-TOPS-20:<ME>FOO.LISP")) => "FOO"
Rationale:
This does not solve the whole pathname problem, but it does improve
the situation for a clearly defined set of very common problems.
Current Practice:
Symbolics Genera implements this behavior.
Cost to Implementors:
While this proposal is compatible with CLtL, it may not be compatible with
the implementations of CLtL which some implementations have chosen.
It is possible to isolate the forced changes to the referenced functions
(MAKE-PATHNAME and the PATHNAME-xxx accessors). Existing functions can be
renamed, and new functions with the same name can be introduced which simply
encapsulate case conversion. No further change is forced.
It may, however, be desirable for an implementation to make a more complete
overhaul of their representation. In implementations where the implementors
feel a need to do this, the amount of work may be considerably greater.
Cost to Users:
Technically, this change is upward compatible.
In fact, since the existing CLtL spec is so poor, nearly everyone relies
heavily on implementation-specific behavior since there is little other
choice. As such, any change is almost certain to break lots of programs,
in usually superficial but nevertheless important ways. However, if we
really make the pathname facility more portable, the user community may be
willing to bear the consequences of these changes.
Cost of Non-Adoption:
We would be contributing to the perpetuation of the existing fiasco of a
pathname system.
Benefits:
The major costs of non-adoption would be avoided.
Aesthetics:
More code is required, but the code supports a simpler user model.
Anything that simplifies the user model of pathnames is going to be an
improvement.
Discussion:
Pitman suports PATHNAME-COMPONENT-CASE:CANONICALIZE.
-------------------------------------------------------------------
There was a lot of debate internally on CL-Cleanup about this one
which reached no resolution. Rather than include that discussion, I
will sum up what I think are the main discussion points:
- Uppercase was proposed as the canonical case because it seemed
most consistent with other parts of the language which are forced
to use a canonical case (such as symbol names and arguments to
macro character handlers).
Some people wish we would use lowercase because they think more
file systems are lowercase.
Note well that the choice of a case as the `canonical case'
internal to Lisp has no technical effect on your ability to
create filenames in upper, lower, or mixed case under this
proposal. This argument is purely an aesthetic one.
The Symbolics file system (upon which this proposal is based)
uses lowercase as the preferred case, and yet the use of uppercase
canonical case has caused no serious technical problems in the
five or so years that we've field tested this appraoch in
an environment that depends critically on heavy use of a variety
of file systems from the same lisp image. This is not a
pie-in-the-sky idea -- it is implemented and has stood the test of time.
- This proposal suggests that functions like PATHNAME-NAME return
and that make-pathname accept strings which are in the interchange
(canonical) case rather than in the native file system case so that
pathname components can be retrieved from one pathname and stored
in a second without regard to whether those two pathnames agreed on
native case.
Some people suggested that PATHNAME-NAME and MAKE-PATHNAME should
work non-portably, using native case information, and that you should
have to do more work (e.g., supply a keyword argument) to get portable
code. This strikes me as incompatible with our goals but is technically
a possible position to take.
Others suggested that two sets of functions should be available --
one set for native case (e.g., MAKE-FILENAME, FILENAME-NAME, ...)
and one for portable case (e.g., MAKE-PATHNAME, PATHNAME-NAME, ...).
These would make the same kind of object -- they would just support
different views on the set of operations that you might want on the
object. If you follow this approach, the issues become ``who gets
which names'' and ``does this make the language gratuitously bloated''?
Some people who wanted parallel paradigms (one for native case, one
for an interchange/canonical case) seemed to be willing to give up
that desire if the canonical case was coincidentally chosen to be the
same as the native case for the file system they worked with.
``I'll compromise as long as I don't have to change.''
- Some people don't use multiple file systems in the same core image
and don't realize how critical an issue this is to those of use who do.
THE BOTTOM LINE:
Users deal with this problem day in and day out as they move back and
forth between different systems. The solution is within our grasp
technically -- the key issues to be resolved are aesthetic and political,
not technical. In the end, users won't want to hear about the political
roadblocks. They are trusting us to come up with a solution and we should
come through. Please be prepared to come at this issue constructively. I
thank you, and our users will ultimately thank you.
∂22-Mar-89 1900 X3J13-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 22 Mar 89 19:00:00 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 325245; Wed 22-Mar-89 21:59:33 EST
Date: Wed, 22 Mar 89 21:59 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
To: X3J13@SAIL.STANFORD.EDU
Message-ID: <19890323025928.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
This is a last minute update of this issue to fix the problems found
during discussion of the previous version. I have fixed typos,
including some critical ones that made the proposal impossible to
understand, standardized terminology, and added specifications for
merging of relative directories and for the subset used in
non-hierarchical file systems.
Issue: PATHNAME-SUBDIRECTORY-LIST
References: Pathnames (pp410-413), MAKE-PATHNAME (p416),
PATHNAME-DIRECTORY (p417)
Category: CHANGE
Edit history: 18-Jun-87, Version 1 by Ghenis.pasa@Xerox.COM
05-Jul-88, Version 2 by Pitman (major revision)
28-Dec-88, Version 3 by Pitman (merge discussion)
22-Mar-89, Version 4 by Moon (fix based on discussion)
Status: Trying to be Released
Related-Issues: PATHNAME-COMPONENT-CASE
Problem Description:
It is impossible to write portable code that can produce a pathname
in a subdirectory of a hierarchical file system. This defeats much of
the purpose of having an abstraction like pathname.
According to CLtL, only a string is a portable value for the directory
component of a pathname, thus in order to denote a subdirectory, the
use of separators (such as dots, slashes, or backslashes) would be
necessary. The very fact that such syntax varies from host to host
means that although the representation might be "portable", the code
using that representation is not portable.
This problem is even worse for programs running on machines on a network
that can retrieve files from multiple hosts, each using a different OS
and thus a different subdirectory delimiter.
Related problems:
- In some implementations "FOO.BAR" might denote the "BAR" subdirectory
of "FOO", while in other implementations it would denote a top-level
directory, because "." is not the separator. To be safe, portable
programs must avoid all potential separators.
- Even in implementations where "." is the separator, "FOO.BAR" may be
recognized by some to mean the "BAR" subdirectory of "FOO" and by others
to mean `a seven letter directory with "." being a superquoted part of
its name'.
- In fact, CLtL does not even say for toplevel directories whether
the directory delimiter characters are part of the string. eg, is
"foo" or "/foo" the directory component for a unix pathname
"/foo/bar.lisp". Similarly, is "[FOO]" or "FOO" the directory
component for a VMS pathname "[FOO]ME.LSP"?
Proposal (PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION)
Remove the "structured" directory feature mentioned on CLtL p.412.
Allow the value of a pathname's directory component to be a list. The
car of the list may be either of the symbols :ABSOLUTE or :RELATIVE.
Each remaining element of the list is a string or one of the keyword
symbols listed below. Each string names a single level of directory
structure. The strings should contain only the directory names
themselves -- no separator characters.
A list whose car is the symbol :ABSOLUTE represents a directory path
starting from the root directory. The list (:ABSOLUTE) represents
the root directory. The list (:ABSOLUTE "foo" "bar" "baz") represents
the directory called "/foo/bar/baz" in Unix [except possibly for
alphabetic case -- that is the subject of a separate issue].
A list whose car is the symbol :RELATIVE represents a directory path
starting from a default directory. The list (:RELATIVE) has the same
meaning as NIL. The list (:RELATIVE "foo" "bar") represents the
directory named "bar" in the directory named "foo" in the default
directory [except possibly for alphabetic case -- that is the subject
of a separate issue].
In place of a string, at any point in the list, keyword symbols may occur
to indicate special file notations. The following symbols have standard
meanings; they may not be meaningful for all operating systems, and are
intended for use only on those operating systems where they have meaning.
Implementations are permitted to add additional keyword symbols if
necessary to represent features of their file systems.
:WILD - Wildcard match of one level of directory structure.
:WILD-INFERIORS - Wildcard match of any number of directory levels.
:UP - Go upward in directory structure (semantic).
:BACK - Go upward in directory structure (syntactic).
"Syntactic" means that the action of :BACK depends only on the pathname
and not on the contents of the file system. "Semantic" means that the
action of :UP depends on the contents of the file system; to resolve
a pathname containing :UP to a pathname whose directory component
contains only :ABSOLUTE and strings requires probing the file system.
:UP differs from :BACK only in file systems that support multiple
names for directories, perhaps via symbolic links. For example,
suppose that there is a directory
(:ABSOLUTE "X" "Y" "Z")
linked to
(:ABSOLUTE "A" "B" "C")
and there also exist directories
(:ABSOLUTE "A" "B" "Q")
(:ABSOLUTE "X" "Y" "Q")
then
(:ABSOLUTE "X" "Y" "Z" :UP "Q")
designates
(:ABSOLUTE "A" "B" "Q")
while
(:ABSOLUTE "X" "Y" "Z" :BACK "Q")
designates
(:ABSOLUTE "X" "Y" "Q")
If a string is used as the value of the :DIRECTORY argument to
MAKE-PATHNAME, it should be the name of a toplevel directory and
should not contain any directory delimiter characters. Specifying a
string, str, is equivalent to specifying the list (:ABSOLUTE str).
Specifying the symbol :WILD is equivalent to specifying the list
(:ABSOLUTE :WILD-INFERIORS), or (:ABSOLUTE :WILD) in a
non-hierarchical file system.
The PATHNAME-DIRECTORY function never returns a string nor :WILD; it
always returns NIL, :UNSPECIFIC, or a list.
In non-hierarchical file systems, the only valid list values for the
directory component of a pathname are (:ABSOLUTE string) and
(:ABSOLUTE :WILD). :RELATIVE directories and the keywords
:WILD-INFERIORS, :UP, and :BACK are not used in non-hierarchical file
systems.
Pathname merging treats a relative directory specially. Let
<pathname> and <defaults> be the first two arguments to
MERGE-PATHNAMES. If (PATHNAME-DIRECTORY <pathname>) is a list whose
car is :RELATIVE, and (PATHNAME-DIRECTORY <defaults>) is a list, then
the merged directory is the value of
(APPEND (PATHNAME-DIRECTORY <defaults>)
(CDR (PATHNAME-DIRECTORY <pathname>)))
except that if the resulting list contains an element other than :BACK
or :WILD-INFERIORS, immediately followed by :BACK, both of them are
removed. This removal of redundant :BACKs is repeated as many times
as possible. If (PATHNAME-DIRECTORY <defaults>) is not a list, the
merged directory is
(OR (PATHNAME-DIRECTORY <pathname>) (PATHNAME-DIRECTORY <defaults>))
A relative directory in the pathname argument to a function such as
OPEN is merged with *DEFAULT-PATHNAME-DEFAULTS* before accessing the
file system.
Test Cases/Examples:
(PATHNAME-DIRECTORY (PARSE-NAMESTRING "[FOO.BAR]BAZ.LSP")) ;on VMS
=> (:ABSOLUTE "FOO" "BAR")
(PATHNAME-DIRECTORY (PARSE-NAMESTRING "/foo/bar/baz.lisp")) ;on Unix
=> (:ABSOLUTE "foo" "bar")
or (:ABSOLUTE "FOO" "BAR")
If PATHNAME-COMPONENT-CASE:CANONICALIZE passes, only the 2nd return value.
(PATHNAME-DIRECTORY (PARSE-NAMESTRING "../baz.lisp")) ;on Unix
=> (:RELATIVE :UP)
(PATHNAME-DIRECTORY (PARSE-NAMESTRING "/foo/bar/../mum/baz")) ;on Unix
=> (:ABSOLUTE "foo" "bar" :UP "mum")
(PATHNAME-DIRECTORY (PARSE-NAMESTRING ">foo>**>bar>baz.lisp")) ;on LispM
=> (:ABSOLUTE "FOO" :WILD-INFERIORS "BAR")
(PATHNAME-DIRECTORY (PARSE-NAMESTRING ">foo>*>bar>baz.lisp")) ;on LispM
=> (:ABSOLUTE "FOO" :WILD "BAR")
Rationale:
This would allow programs to usefully deal with hierarchical file
systems, which are by far the most common file system type.
Current Practice:
Symbolics Genera implements something very similar to this. The main
differences are:
- In Genera, there is no :ABSOLUTE keyword at the head of the list.
This has been shown to cause some problems in dealing with root
directories. Genera represents the root directory by a keyword
symbol (rather than a list) because the list representation
was not adequately general.
- Genera represents Unix ".." as :UP, but deals with :UP
syntactically, not semantically.
Cost to Implementors:
In principle, nothing about the implementation needs to change except
the treatment of the directory component by MAKE-PATHNAME and
PATHNAME-DIRECTORY. The internal representation can otherwise be left
as-is if necessary.
Implementations such as Genera that already have hierarchical directory
handling will have to make an incompatible change to switch to what
is proposed here.
For implementations that choose to rationalize this representation
throughout their internals and any other implementation-specific
accessors, the cost will be necessarily higher.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Serious portability problems would continue to occur. Programmers would be
driven to the use of implementation-specific facilities because the need
for this is frequently impossible to ignore.
Benefits:
The serious costs of non-adoption would be avoided.
Aesthetics:
This representation of hierarchical pathnames is easy to use and quite
general. Users will probably see this as an improvement in the aesthetics.
Discussion:
This issue was raised a while back but no one was fond of the particular
proposal that was submitted. This is an attempt to revive the issue.
The original proposal, to add a :SUBDIRECTORIES component to a
pathname, was discarded because it imposed an unnatural distinction
between a toplevel directory and its subdirectories. Pitman's guess is
the the idea was to try to make it a compatible change, but since most
programmers will probably want to change from implementation-specific
primitives to portable ones anyway, that's probably not such a big
deal. Also, there might have been some programs which thought the
change was compatible and ended up ignoring important information (the
:SUBDIRECTORIES component). Pitman thought it would be better if
people just accepted the cost of an incompatible change in order to
get something really pretty as a result.
Moon doesn't like having both :UP and :BACK, but admits that some
file systems do it one way and some do it the other.
To keep it simple, we chose not to add to this issue the functions
DIRECTORY-PATHNAME-AS-FILE and PATHNAME-AS-DIRECTORY, which convert
the name of a directory from or to the directory component of a file
inferior to that directory. This conversion is system-dependent, for
example TOPS-20 appends a type field and Unix does not. Also in some
systems the root directory has a name and in others it doesn't. Of
course these functions signal an error in non-hierarchical file
systems.
∂22-Mar-89 2031 X3J13-mailer Issue: PATHNAME-COMPONENT-CASE (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Mar 89 20:30:42 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 563397; Wed 22-Mar-89 23:30:16 EST
Date: Wed, 22 Mar 89 23:30 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-COMPONENT-CASE (Version 2)
To: X3J13@SAIL.STANFORD.EDU
Message-ID: <19890323043004.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
I updated and rewrote this issue based on the discussion last Summer and
Autumn that followed the publication of version 1 within the cleanup
committee. Perhaps we can use this as the basis for a constructive
discussion and get this issue out of the way.
This issue contains four alternative proposals.
Issue: PATHNAME-COMPONENT-CASE
References: Pathnames (pp410-413),
MAKE-PATHNAME (p416),
PATHNAME-HOST (p417),
PATHNAME-DEVICE (p417),
PATHNAME-DIRECTORY (p417),
PATHNAME-NAME (p417),
PATHNAME-TYPE (p417)
Category: CHANGE
Edit history: 1-Jul-88, Version 1 by Pitman
22-Mar-89, Version 2 by Moon, update and rewrite
Status: Trying to be ready for release
Problem Description:
Issues of alphabetic case in pathnames are a major source of problems.
In some file systems, the customary case is lowercase, in some
uppercase, in some mixed. In some file systems, case matters, in
others it does not.
There are two kinds of portability problems connected with case in
pathnames: moving programs from one Common Lisp to another, and moving
pathname component values from one file system to another. To solve
the first problem, all Common Lisp implementations that support a
particular file system must use compatible representations for
pathname component values. To solve the second problem, there must be
a canonical representation for pathname component values that means
the same thing on all file systems.
The desire for a canonical representation for pathname component
values directly conflicts with the desire among programmers who only
use one file system to work with the local conventions and not to
have to think about issues of porting to other file systems. The
canonical representation cannot be the same as every local
convention, since they vary.
In the current anarchy of pathname component case conventions:
(NAMESTRING (MAKE-PATHNAME :NAME "FOO" :TYPE "LISP"))
will produce foo.lisp in some Unix Common Lisp implementations
and will produce FOO.LISP in other Unix Common Lisp implementations.
(NAMESTRING (MAKE-PATHNAME :NAME "foo" :TYPE "lisp"))
will produce FOO.LISP in some Tops-20 Common Lisp implementations
and will produce "↑Vf↑Vo↑Vo.↑Vl↑Vi↑Vs↑Vp"in other Tops-20 Common
Lisp implementations.
Problems like this make it difficult to use MAKE-PATHNAME for much of
anything without corrective (non-portable) code.
Other problems occur in merging because doing
(NAMESTRING (MERGE-PATHNAMES (MAKE-PATHNAME :HOST "MY-TOPS-20" :NAME "FOO")
(PARSE-NAMESTRING "MY-UNIX:x.lisp")))
should probably return "MY-TOPS-20:FOO.LISP" but in fact might return
"MY-TOPS-20:FOO.↑Vl↑Vi↑Vs↑Vp" in some implementations.
Problems like this make it difficult to use any merging primitives for
much of anything without corrective (non-portable) code.
Proposal (PATHNAME-COMPONENT-CASE:CANONICALIZE):
Designate a treatment for case in pathname components which is
distinct from the treatment of case in the namestrings. The treatment
should be invariant across operating systems. Namestrings use local
file system case conventions, pathname components use common case
conventions.
Arbitrarily choose uppercase as the common (or universal) case.
If a string given to MAKE-PATHNAME, or returned by any of the
PATHNAME-xxx accessor operations, is all uppercase, it is said to
designate a name in the system's "canonical case".
If a string given to MAKE-PATHNAME, or returned by any of the
PATHNAME-xxx accessor operations, is all lowercase, it is said to
designate a name in the system's "anticanonical case".
If a string given to MAKE-PATHNAME, or returned by any of the
PATHNAME-xxx accessor operations, is mixed case, it is said to
designate a name in exactly the indicated case.
Functions such as PARSE-NAMESTRING and NAMESTRING which convert from
or to local file system syntax will perform any necessary conversions
between "canonical case" and the host's customary case, and between
"anticanonical case" and the opposite of the host's customary case.
Proposal (PATHNAME-COMPONENT-CASE:NEW-COMMON-ACCESSORS):
Add new pathname component accessor functions that return values
translated to the common case defined above. Use the local file
system case conventions in the existing pathname component accessor
functions. The new accessors are named PATHNAME-COMMON-DEVICE,
PATHNAME-COMMON-DIRECTORY, PATHNAME-COMMON-NAME, and
PATHNAME-COMMON-TYPE.
Add new keyword arguments to MAKE-PATHNAME that accept values in the
the common case defined above and translate to the host's customary
case. Use the local file system case conventions in the existing
keyword arguments to MAKE-PATHNAME. The new keyword arguments are
named :COMMON-DEVICE, :COMMON-DIRECTORY, :COMMON-NAME, and
:COMMON-TYPE.
Proposal (PATHNAME-COMPONENT-CASE:NEW-LOCAL-ACCESSORS):
Do everything proposed for PATHNAME-COMPONENT-CASE:CANONICALIZE,
and in addition:
Add new pathname component accessor functions that return values in
the local file system case conventions. The new accessors are named
PATHNAME-LOCAL-DEVICE, PATHNAME-LOCAL-DIRECTORY, PATHNAME-LOCAL-NAME,
and PATHNAME-LOCAL-TYPE.
Add new keyword arguments to MAKE-PATHNAME that accept values in the
local file system case conventions. The new keyword arguments are
named :LOCAL-DEVICE, :LOCAL-DIRECTORY, :LOCAL-NAME, and :LOCAL-TYPE.
Proposal (PATHNAME-COMPONENT-CASE:KEYWORD-ARGUMENT):
Add a keyword argument :CASE to MAKE-PATHNAME and the PATHNAME-xxx
accessors, indicating whether common or local conventions should be
followed. The possible values for the argument are :COMMON and
:LOCAL. The default is :COMMON.
Test Case:
Under PATHNAME-COMPONENT-CASE:CANONICALIZE:
(PATHNAME-NAME (PARSE-NAMESTRING "MY-UNIX:/me/foo.lisp")) => "FOO"
(PATHNAME-NAME (PARSE-NAMESTRING "MY-TOPS-20:<ME>FOO.LISP")) => "FOO"
Under PATHNAME-COMPONENT-CASE:NEW-COMMON-ACCESSORS:
(PATHNAME-NAME (PARSE-NAMESTRING "MY-UNIX:/me/foo.lisp")) => "foo"
(PATHNAME-NAME (PARSE-NAMESTRING "MY-TOPS-20:<ME>FOO.LISP")) => "FOO"
(PATHNAME-COMMON-NAME (PARSE-NAMESTRING "MY-UNIX:/me/foo.lisp")) => "FOO"
(PATHNAME-COMMON-NAME (PARSE-NAMESTRING "MY-TOPS-20:<ME>FOO.LISP")) => "FOO"
Under PATHNAME-COMPONENT-CASE:NEW-LOCAL-ACCESSORS:
(PATHNAME-NAME (PARSE-NAMESTRING "MY-UNIX:/me/foo.lisp")) => "FOO"
(PATHNAME-NAME (PARSE-NAMESTRING "MY-TOPS-20:<ME>FOO.LISP")) => "FOO"
(PATHNAME-LOCAL-NAME (PARSE-NAMESTRING "MY-UNIX:/me/foo.lisp")) => "foo"
(PATHNAME-LOCAL-NAME (PARSE-NAMESTRING "MY-TOPS-20:<ME>FOO.LISP")) => "FOO"
Under PATHNAME-COMPONENT-CASE:KEYWORD-ARGUMENT:
(PATHNAME-NAME (PARSE-NAMESTRING "MY-UNIX:/me/foo.lisp")
:CASE :COMMON) => "FOO"
(PATHNAME-NAME (PARSE-NAMESTRING "MY-TOPS-20:<ME>FOO.LISP")
:CASE :COMMON) => "FOO"
(PATHNAME-NAME (PARSE-NAMESTRING "MY-UNIX:/me/foo.lisp")
:CASE :LOCAL) => "foo"
(PATHNAME-NAME (PARSE-NAMESTRING "MY-TOPS-20:<ME>FOO.LISP")
:CASE :LOCAL) => "FOO"
Rationale:
This does not solve the whole pathname problem, but it does improve
the situation for a clearly defined set of very common problems.
Together with the other pathname proposals, the behavior of pathnames
should be sufficiently consistent across Common Lisp implementations
and across file systems to allow portability of pathname-manipulating
programs.
Upper case is chosen as the canonical case for no better reason than
consistency with the canonical case for Lisp symbols.
PATHNAME-COMPONENT-CASE:CANONICALIZE minimizes the size of the
language by not adding any new functions. It assumes that pathname
operations using local file system conventions can be performed on
namestrings and that anything that calls MAKE-PATHNAME or the
PATHNAME-xxx accessors is portable code that is independent of the
local file system conventions.
PATHNAME-COMPONENT-CASE:NEW-COMMON-ACCESSORS assumes that the existing
MAKE-PATHNAME and PATHNAME-xxx accessor features are for programs that
only work on one file system and that more generally portable programs
should use new features.
PATHNAME-COMPONENT-CASE:NEW-LOCAL-ACCESSORS assumes that the existing
MAKE-PATHNAME and PATHNAME-xxx accessor features are for fully
portable programs but that PATHNAME-COMPONENT-CASE:CANONICALIZE is
insufficient and direct access to the local conventions is required.
PATHNAME-COMPONENT-CASE:KEYWORD-ARGUMENT assumes that access to both
conventions is necessary but introducing more functions is bad.
The default convention is the common one, assuming that most
programs are fully portable.
Note:
None of these proposals requires an implementation to change its
internal representation. They only require the canonical accessors to
behave as if the internal representation had been changed. Whether
the actual internal representation is changed is still up to an
implementation. A consequence of this is that if pathnames print in a
way that shows the components individually (such as #S), they are not
constrained to print the components in any particular case; they are
constrained only to have definite syntax conventions and to be able to
invert those conventions at the appropriate time. Any change to the
way pathnames print is beyond the scope of this proposal.
There should probably be a remark somewhere that says that portable
programs shouldn't expect to be able to create and/or access distinct
files whose pathname components differ only in case.
Current Practice:
Symbolics Genera implements something resembling
PATHNAME-COMPONENT-CASE:NEW-LOCAL-ACCESSORS except that the names use
"raw" rather than "local". The "raw" accessors are almost never used.
Symbolics Genera's own file system uses lower case as the customary
case, but transparent network access is available to file systems
using all known case conventions.
Many Common Lisp implementations that only deal with a single file
system implement something resembling
PATHNAME-COMPONENT-CASE:NEW-COMMON-ACCESSORS except without the
new accessors and keyword arguments.
Cost to Implementors:
While all of these proposals are compatible with CLtL, since CLtL is
so vague, they are not likely to be compatible with the
implementations of CLtL which some implementations have chosen.
It is possible to isolate the forced changes to the referenced functions
(MAKE-PATHNAME and the PATHNAME-xxx accessors). Existing functions can be
renamed, and new functions with the same name can be introduced which simply
encapsulate case conversion. No further change is forced.
It may, however, be desirable for an implementation to make a more complete
overhaul of their representation. In implementations where the implementors
feel a need to do this, the amount of work may be considerably greater.
Cost to Users:
Technically, this change is upward compatible.
In fact, since the existing CLtL spec is so poor, nearly everyone relies
heavily on implementation-specific behavior since there is little other
choice. As such, any change is almost certain to break lots of programs,
in usually superficial but nevertheless important ways. However, if we
really make the pathname facility more portable, the user community may be
willing to bear the consequences of these changes.
Cost of Non-Adoption:
We would be contributing to the perpetuation of the existing fiasco of a
pathname system.
Benefits:
The major costs of non-adoption would be avoided.
Aesthetics:
More code is required, but the code supports a simpler user model.
Anything that simplifies the user model of pathnames is going to be an
improvement.
Discussion:
Some people would rather use lowercase as the canonical case. The
decision is essentially arbitrary. Everywhere else in Common Lisp
where there is a canonical case, uppercase was chosen.
It has been proposed that the Common Lisp specification should include
specifications of the exact behavior of pathnames for several popular
operating systems, so that multiple implementations for those
operating systems would be compatible with each other. This proposal
does not attempt to do that, only to establish the coherent framework
within which it would be done.
In PATHNAME-COMPONENT-CASE:KEYWORD-ARGUMENT, some people want the
default for :CASE to be :LOCAL instead of :COMMON. I would have
written that up too, but I thought five proposals were too many.